Re: [patch 4/8] futex: Add support for unlocking robust futexes

[Peter Zijlstra]

On Wed, Mar 18, 2026 at 09:02:01AM +0100, Peter Zijlstra wrote:
> On Tue, Mar 17, 2026 at 11:40:12PM +0100, Thomas Gleixner wrote:
> > On Tue, Mar 17 2026 at 21:46, Peter Zijlstra wrote:
> > > On Tue, Mar 17, 2026 at 01:17:28PM -0300, André Almeida wrote:
> > >> Em 16/03/2026 14:13, Thomas Gleixner escreveu:
> > >> 
> > >> [...]
> > >> 
> > >> > --- a/kernel/futex/waitwake.c
> > >> > +++ b/kernel/futex/waitwake.c
> > >> > @@ -150,12 +150,32 @@ void futex_wake_mark(struct wake_q_head
> > >> >   }
> > >> >   /*
> > >> > + * If requested, clear the robust list pending op and unlock the futex
> > >> > + */
> > >> > +static bool futex_robust_unlock(u32 __user *uaddr, unsigned int flags, void __user *pop)
> > >> > +{
> > >> > +	if (!(flags & FLAGS_UNLOCK_ROBUST))
> > >> > +		return true;
> > >> > +
> > >> > +	/* First unlock the futex. */
> > >> > +	if (put_user(0U, uaddr))
> > >> > +		return false;
> > >> > +
> > >> 
> > >> On glibc code, the futex unlock happens atomically:
> > >> 
> > >>     atomic_exchange_release (&mutex->__data.__lock, 0)
> > >> 
> > >> Is OK to do it unatomically?
> > >> 
> > >> I couldn't find a race condition given that the only thread that should be
> > >> able to write to the futex address must be the lock owner anyways, but I
> > >> don't know why userspace does it atomically in the first place.
> > >
> > > So userspace could probably get away with doing:
> > >
> > >    atomic_store_explicit(&mutex->__data.__lock, 0, memory_order_release);
> > >
> > > IOW a plain store-release. And yeah, I think the kernel probably should
> > > do a store-release too. It doesn't matter on x86, but if we have a
> > > weakly ordered architecture where the mode transition is also not
> > > serializing, we could be having trouble.
> > 
> > No. There is a syscall in between and if that is not sufficient then the
> > architecure has more severe troubles than that store, no?
> 
> So I think we once tried to determine if syscall could be considered to
> imply memory ordering, and I think the take-away at the time was that we
> could not assume so.
> 
> But its been a long time, maybe I misremember.

Ah, it was for the sys_membarrier() thing. And yes, a syscall itself
does not imply memory ordering for all architectures. And since this
very much needs release semantics, it is best to be explicit about that.