Re: [patch v2 00/11] futex: Address the robust futex unlock race for real

[Rich Felker <dalias@aerifal.cx>]

On Fri, Mar 27, 2026 at 12:42:35AM -0300, André Almeida wrote:
> Em 26/03/2026 19:08, Rich Felker escreveu:
> > On Thu, Mar 26, 2026 at 10:59:20PM +0100, Thomas Gleixner wrote:
> > > On Fri, Mar 20 2026 at 00:24, Thomas Gleixner wrote:
> > > > If the functionality itself is agreed on we only need to agree on the names
> > > > and signatures of the functions exposed through the VDSO before we set them
> > > > in stone. That will hopefully not take another 15 years :)
> > > 
> > > Have the libc folks any further opinion on the syscall and the vDSO part
> > > before I prepare v3?
> > 
> > This whole conversation has been way too much for me to keep up with,
> > so I'm not sure where it's at right now.
> > 
> >  From musl's perspective, the way we make robust mutex unlocking safe
> > right now is by inhibiting munmap/mremap/MAP_FIXED and
> > pthread_mutex_destroy while there are any in-flight robust unlocks. It
> > will be nice to be able to conditionally stop doing that if vdso is
> > available, but I can't see using a fallback that requires a syscall,
> > as that would just be a lot more expensive than what we're doing right
> > now and still not work on older kernels. So I think the only part
> > we're interested in is the fully-userspace approach in vdso.
> > 
> 
> You just need the syscall for the contented case (where you would need a
> syscall anyway for a FUTEX_WAKE).
> 
> As Thomas wrote in patch 09/11:
> 
>   The resulting code sequence for user space is:
> 
>   if (__vdso_futex_robust_list$SZ_try_unlock(lock, tid, &pending_op) != tid)
>  	err = sys_futex($OP | FUTEX_ROBUST_UNLOCK,....);
> 
>   Both the VDSO unlock and the kernel side unlock ensure that the pending_op
> pointer is always cleared when the lock becomes unlocked.
> 
> 
> So you call the vDSO first. If it fails, it means that the lock is contented
> and you need to call futex(). It will wake a waiter, release the lock and
> clean list_op_pending.

So would we use the vdso function presence as signal that this
functionality is available? In that case, I think what we would do is:

1. Try an uncontended unlock using the vdso.
2. If it fails, attempt FUTEX_ROBUST_UNLOCK.
3. If that fails (note: this could be due to seccomp!), fallback to
the old kernel code path, holding off any munmap/etc. while we perform
the userspace unlock.

The path where the vdso function is missing would go straight to 3.

Does this sound right?

Rich