Hi Ben, > Well, the main issue here is leaking kernel reservations into userspace, > and thus the question of whether it is a big deal or not. There's also > an issue I can see with signals. > > The risk with kernel reservations leaking into userspace is a problem on > some processors that do not compare the reservation address locally > (only for snoops), thus userspace code doing lwarx/syscall/stwcx. might > end up with a suceeding stwcx. despite the fact that the original > reservation was long lost.
Yeah that was my primary concern. Right now these things fail 100%, so no one is relying on it. The worry is if people start writing their own crazy low level system call + locking stubs that might work most of the time (if we remove the stwcx in syscall exit). > At this stage it becomes an ABI problem, ie, whether we define the > behaviour of a lwarx/stwcx. accross a syscall as defined or not. > > The other problem I see is that signal handlers would have to be made > very careful not to leave dangling reservations since the return from > the syscall is a syscall, unless we add code specifically to this (and > set_context too I'd say) to clear reservations. > > IE. You could have something like: > > lwarx, <interrupt>, signal handler, sigreturn, stwcx. > > In the above case, the reservation would be cleared by the return from > the interrupt, but the signal handler might leave a dangling one, which > sigreturn might fail to clear (in practice, our current implementation > of sys_sigreturn() will probably clear any reservation as a side effect > of restore_sigmask() spinlock or set_thread_flag() but it sounds a bit > fragile to rely on unless it's well documented). Good point, I hadn't thought of signals and I agree we'd need to clear the reservation in the sigreturn path. Anton _______________________________________________ Linuxppc-dev mailing list [email protected] https://lists.ozlabs.org/listinfo/linuxppc-dev
