Chuck Ebbert wrote:
Nevermind. I thought because you changed struct pt_regs in ptrace_abi.h
it meant a user ABI change.
Yes, that header seems pretty badly misnamed. The user-visible
structure is user_pt_regs.
But they can get out of sync, e.g. when switch_to() restores the new
task's esp, the PDA still contains the old pcurrent and they don't get
synchronized until the write_pda() in __switch_to().
Yes, that's true, but the window is fairly small. More importantly, the
question of "what task is currently running" is fundamentally
ill-defined while you're in the middle of a context switch, so I don't
think this is a big issue. __switch_to runs on the new task's stack, so
that's effectively where current_thread_info()->task changes value
(aside from the few instructions in switch_to() between the %esp update
and the jmp to __switch_to). I could put the write_pda() earlier in
__switch_to so the window is smaller. But again, for it to make a
difference, someone would want to be using current *within* __switch_to,
which is just silly.
To be honest, I haven't looked at percpu.h in great detail. I was
making assumptions about how it works, but it looks like they were wrong.
Would it make any sense to replace the 'cpu' field in thread_info with
a pointer to a PDA-like structure? We could even embed the static per_cpu
data directly into that struct instead of chasing pointers...
I don't think so. The whole point is to make the pda easily accessible
with simple addressing modes based on %gs:. I have been wondering if
we can modify the percpu mechanism to get the linker to construct the
layout of the pda, so that all the existing percpu stuff can be
transparently moved into the pda and accessed efficiently. I think it
would be pretty tricky to get it all working though...
But the PDA isn't really intended for *all* per-cpu data; its mostly for
stuff which is accessed often, or needs to be quickly and easily
accessibly. My specific motivation is to use the PDA for easy access to
Xen per-cpu data, which needs to be accessible with short instructions
which can be inlined.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
