* Mathieu Desnoyers:

On 2026-03-02 02:31, Florian Weimer wrote:

quoted

* Mathieu Desnoyers:

quoted

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.

quoted

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