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

[Peter Zijlstra]

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.