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

[Mathieu Desnoyers]

On 2026-03-02 11:42, Florian Weimer wrote:
> * Mathieu Desnoyers:
[...]
> > AFAIU we don't need to evaluate this on context switch. We only need
> > to evaluate it at:
> >
> > (a) Signal delivery,
> > (b) Process exit.
>
> Ah, missed that part.  It changes the rules somewhat.
>
> > Also, the tradeoff here is not clear cut to me: the only thing the rseq
> > flag would prevent is comparisons of the instruction pointer against a
> > vDSO range at (a) and (b), which are not as performance critical as
> > context switches. I'm not sure it would warrant the added complexity of
> > the rseq flag, and coupling with rseq. Moreover, I'm not convinced that
> > loading an extra rseq flag field from userspace would be faster than
> > just comparing with a known range of vDSO addresses.
>
> It wouldn't work for the signal case anyway.  That would need space in
> rseq for some kind of write-ahead log of the operation before it's being
> carried out, so that it can be completed on signal delivery/process
> exit.

The signal handler case can be dealt with by making sure we clear the
pending ops list on signal delivery. AFAIU with that in place we would
not need a write-ahead log. But even then, I don't think the rseq flag
would bring any benefit over simple vDSO instruction pointer ranges
comparisons.

Also the rseq flag set/clear cannot be done atomically with respect
to the mutex unlock (success) and pending ops clear state transitions,
so we'd need instruction pointer comparisons anyway.

Thanks,

Mathieu

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