On 06/24/11 11:11, Marcel Moolenaar wrote:
On Jun 23, 2011, at 3:21 PM, Nathan Whitehorn wrote:
Author: nwhitehorn
Date: Thu Jun 23 22:21:28 2011
New Revision: 223485
URL: http://svn.freebsd.org/changeset/base/223485
Log:
Use the ABI-mandated thread pointer register (r2 for ppc32, r13 for ppc64)
instead of a PCPU field for curthread. This averts a race on SMP systems
with a high interrupt rate where the thread looking up the value of
curthread could be preempted and migrated between obtaining the PCPU
pointer and reading the value of pc_curthread, resulting in curthread being
observed to be the current thread on the thread's original CPU. This played
merry havoc with the system, in particular with mutexes. Many thanks to
jhb for helping me work this one out.
Nice catch!
Another approach would be to have r2/r13 hold the address of the PCPU
structure and simply do a load from that address to get curthread.
The difference between the approaches is the need to to a memory load
or not for curthread. But with r2/r13 pointing to the PCPU, you may
be faster to get other PCPU fields if reading from the a SPR adds to
the overhead. Plus, it's easier to be atomic if you don't have to
read the SPR first and then do a load.
The trouble with this approach is that r2/r13 would need to be updated
on every CPU switch with the new PCPU pointer, so I just put curthread
in there due to laziness, which is of course constant for a given
thread. Another consideration is that we'd have to additionally maintain
SPRG0 as the PCPU pointer anyway, since we need a PCPU area that
userland can't change (r2/r13 is set from PCPU data when traps are taken
now).
Is curthread the only field that needs to be atomically accessed or
are other fields in the PCPU susceptible to race conditions?
In my discussion with John yesterday, he said he thought it was the only
one susceptible to races of this type. The approach I used here
(providing a special accessor for curthread that reads a
non-PCPU-related register) is borrowed from the one used on amd64, i386,
and alpha. Whether it is the only possibility for this kind of race or
not, none of these platforms at least override anything else.
-Nathan
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[email protected]"
