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

[Rich Felker]

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.

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