On Sat, Oct 24, 2015 at 07:53:56PM +0800, Boqun Feng wrote: > On Sat, Oct 24, 2015 at 12:26:27PM +0200, Peter Zijlstra wrote: > > > > Right, futexes are a pain; and I think we all agreed we didn't want to > > go rely on implementation details unless we absolutely _have_ to. > > > > Agreed. > > Besides, after I have read why futex_wake_op(the caller of > futex_atomic_op_inuser()) is introduced, I think your worries are quite > reasonable. I thought the futex_atomic_op_inuser() only operated on > futex related variables, but it turns out it can actually operate any > userspace variable if userspace code likes, therefore we don't have > control of all memory ordering guarantee of the variable. So if PPC > doesn't provide a full barrier at user<->kernel boundries, we should > make futex_atomic_op_inuser() fully ordered. > > > Still looking into futex_atomic_cmpxchg_inatomic() ... > I thought that the futex related variables (userspace variables that the first parameter of futex system call points to) are only accessed by futex system call in userspace, but it turns out not the fact. So memordy ordering guarantees of these variables are also out of the control of kernel. Therefore we should make futex_atomic_cmpxchg_inatomic() fully ordered, of course, if PPC doesn't provide a full barrier at user<->kernel boundries.. Regards Boqun
Attachment:
signature.asc
Description: PGP signature