svn commit: r223485 - in head/sys/powerpc: aim booke include
ofw powerpc
Nathan Whitehorn
nwhitehorn at freebsd.org
Fri Jun 24 16:18:38 UTC 2011
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
More information about the svn-src-head
mailing list