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

[Florian Weimer <fweimer@redhat.com>]

* Mathieu Desnoyers:

> 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.

I don't have a performance concern there.  It would be specific to
robust mutexes.

>> 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.

If the unlock operation is in the vDSO, we need to parameterize it
somehow, regarding offsets, values written etc., so that it's not
specific to exactly one robust mutex implementation.

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

It's so that you don't have to figure out that the program counter is
somewhere in the special robust mutex unlock code every time a task gets
descheduled.

Thanks,
Foorian