* Mathieu Desnoyers:
----- On Jan 7, 2022, at 2:31 PM, Florian Weimer fw@deneb.enyo.de wrote:
quoted
* 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 ?
You could perhaps push a signal frame onto the stack. It's going to
be expensive, but it's already in the context switch path, so maybe it
does not matter.
----- On Jan 12, 2022, at 10:16 AM, Florian Weimer fw@deneb.enyo.de wrote:
* Mathieu Desnoyers:
quoted
----- On Jan 7, 2022, at 2:31 PM, Florian Weimer fw@deneb.enyo.de wrote:
quoted
* 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 ?
You could perhaps push a signal frame onto the stack. It's going to
be expensive, but it's already in the context switch path, so maybe it
does not matter.
The route I'm taking in my subsequent version of the patch is very close to
pushing a signal frame: on abort, skip the redzone, and push the abort-at-ip
pointer. Then abort handler is then expected to pop the abort-at-ip pointer
and unskip the redzone.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
On Wed, Jan 12, 2022 at 04:16:36PM +0100, Florian Weimer wrote:
You could perhaps push a signal frame onto the stack. It's going to
be expensive, but it's already in the context switch path, so maybe it
does not matter.
Please no! Signals are a trainwreck that need change (see the whole
AVX-512 / AMX saga), we shouldn't use more of that just cause.