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

[Peter Zijlstra]

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.