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

[Thomas Gleixner <tglx@kernel.org>]

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?

Thanks,

        tglx