Using __kuser_cmpxchg

Andrew Haley aph@redhat.com
Fri Nov 16 09:52:00 GMT 2007


Nicolas Pitre writes:
 > On 2007年11月15日, Andrew Haley wrote:
 > 
 > > Nicolas Pitre writes:
 > > > On 2007年11月15日, Andrew Haley wrote:
 > > > 
 > > > In the mean time you can work around it by using a mutex around the 
 > > > thread state modification instead of using cmpxchg on it. Or if your 
 > > > platform is ARMv6 or higher then you won't get those spurious false 
 > > > negatives.
 > > 
 > > Ah, OK, that's interesting: it sounds like you understand under what
 > > circumstances it may fail "spuriously".
 > 
 > Heh, I wrote that code (and comment). :-)
 > 
 > > What are these?
 > 
 > On a pre-ARMv6 processor, there is no way to implement a truly
 > atomic user space cmpxchg without disabling interrupts, which can
 > be done only from kernel space. And going to kernel space only for
 > atomically modifying a single value in memory is rather
 > prohibitive.
 > 
 > However, on a non SMP machine, the only thing that can break user
 > space atomicity is a processor exception. When an exception occurs
 > because of an IRQ or a page fault, the kernel may well decide to
 > schedule another user process or thread unexpectedly.
 > 
 > So we cheat a bit by simply performing the load+compare+store with 
 > plain standard instructions as follows:
 > 
 > teq ip, ip @ set Z flag
 > ldr ip, [r2] @ load current val
 > add r3, r2, #1 @ prepare store ptr
 > teqeq ip, r0 @ compare with oldval if still allowed
 > streq r1, [r3, #-1]! @ store newval if still allowed
 > subs r0, r2, r3 @ if r2 == r3 the str occured
 > 
 > But there is a twist such that if ever an exception occurs during that 
 > sequence, the Z flag is cleared by the exception handler before that 
 > sequence is resumed and the store won't occur.
Ok, please stop there. I don't understand this at all: if an
exception occurs surely we'll save and restore the flags. How is it
possible for an exception to corrupt the user space Z flag?
Andrew.
-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /