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

[André Almeida]

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.

> If it sounds like I have a misconception of the current state of this
> proposal from what I said above, let me know and I'll try to figure
> out what I'm missing and catch up.
>
> Rich