Re: [RFC PATCH 0/2] futex: how to solve the robust_list race condition?

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-03-02 02:31, Florian Weimer wrote:
> * Mathieu Desnoyers:
> 
>> Of course, we'd have to implement the whole transaction in assembler
>> for each architecture.
> 
> Could this be hidden ina vDSO call?

Yes, good idea! I think this approach could work as well and reduce coupling
between kernel and userspace compared to the rseq_rl_cs approach. It's OK
as long as an extra function call on robust mutex unlock is not an issue
performance wise.

> It would have to receive a pointer
> to the rseq area in addition to other arguments that identify the unlock
> operation to be performed.  The advantage is that the kernel would now> the addresses involved, so a single rseq flag should be sufficient.

But if we implement the robust list unlock operation in a vDSO, if we
don't consider signal handlers nesting, then we would not even need a
rseq flag, right ?

Having this in a vDSO makes it so that the kernel knows when it's
terminating a process while it runs specific ranges of instruction
pointers within the vDSO. It even knows about the relevant registers
(e.g. ll/sc success) within specific instruction pointer ranges.

The remaining question is how to handle signal handlers which can
nest over vDSO. When this happens, we can end up terminating a process
while it is running within a signal handler which has been delivered on
top of the vDSO, so the topmost frame's instruction pointer points to
the signal handler code rather than the vDSO.

One possible approach to take care of this would be to add a robust list
pending ops clear on signal delivery. When a signal is delivered
on top of the robust list unlock vDSO range, *and* the mutex is known
to have been successfully unlocked, but the pending ops was not cleared
yet, the signal delivery could clear the pending ops before delivering
the signal.

> It
> could also vary the LL/SC sequence based on architecture capabilities.

Yes. I would be good for selecting dynamically between aarch64 LL/SC vs
LSE atomics.

> 
> The question is whether we can model the unlock operation so that it's
> sufficiently generic.

I suspect the IP ranges and associated store-conditional flags I identified
for the rseq_rl_cs approach are pretty much the key states we need to track.
Architectures which support atomic exchange instructions are even simpler.
We'd just have to keep track of this unlock operations steps internally
between the kernel and the vDSO.

But you mentioned that rseq would be needed for a flag, so what I am
missing ?

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com