This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using __kuser_cmpxchg


Andrew Haley wrote:
Nicolas Pitre writes:
> 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?

Look in arch/arm/kernel/entry-armv.S the usr_entry macro.

There are special code in the exception handler to detect if we come from __kuser_cmpxchg code and clear the Z flags.


Matthieu



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]