Re: [RFC PATCH] rseq: x86: implement abort-at-ip extension

----- On Jan 7, 2022, at 2:31 PM, Florian Weimer fw@deneb.enyo.de wrote:

* Mathieu Desnoyers:

quoted

Allow rseq critical section abort handlers to optionally figure out at
which instruction pointer the rseq critical section was aborted.

This allows implementing rseq critical sections containing loops, in
which case the commit side-effect cannot be the last instruction. This
is useful to implement adaptative mutexes aware of preemption in
user-space. (see [1])

Could you write the program counter to the rseq area instead?  This
would avoid discussing which register to clobber.

Using the rseq area for that purpose would be problematic for nested signal
handlers with rseq critical sections. If a signal happens to be delivered
right after the abort ip adjustment, its signal handler containing a rseq
critical section could overwrite the relevant "abort-at-ip" field in the
rseq per-thread area before it has been read by the abort handler interrupted
by the signal.

Making this architecture-agnostic is indeed a laudable goal, but I don't
think the rseq per-thread area is a good fit for this.

I also though about making the clobbered register configurable on a
per-critical-section basis, but I rather think that it would be
overengineered: too much complexity for the gain. Unless there are
very strong reasons for choosing one register over another on a per
use-case basis ?

I guess if we ever care about the state of a given register within a given
range of instructions, we may lose that information if it is overwritten
by the abort-at-ip value. For instance, in my adaptative mutex prototype,
I use the Zero Flag to check if cmpxchg has succeeded. But if I would have
wanted to use the register modified by cmpxchg, and it would happen to be
clobbered by the abort-at-ip on abort, then it limits what the abort handler
can observe. It's fine as long as instructions can select what registers they
operate on, but instructions like cmpxchg AFAIR work on specific registers,
which might warrant making the abort-at-ip register configurable per
critical section. But maybe just choosing a register for abort-at-ip which
is not typically used by instructions that rely on hardcoded registers might
be sufficient.

Thoughts ?

Thanks,

Mathieu

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