Message-ID: <1300078200.13848.1641590867024.JavaMail.zimbra@efficios.com>
Date:   Fri, 7 Jan 2022 16:27:47 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Florian Weimer <fw@...eb.enyo.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        paulmck <paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        "H. Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
        linux-api <linux-api@...r.kernel.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        carlos <carlos@...hat.com>
Subject: Re: [RFC PATCH] rseq: x86: implement abort-at-ip extension

----- On Jan 7, 2022, at 2:48 PM, Mathieu Desnoyers mathieu.desnoyers@...icios.com wrote:

> ----- On Jan 7, 2022, at 2:31 PM, Florian Weimer fw@...eb.enyo.de wrote:
> 
>> * Mathieu Desnoyers:
>> 
>>> 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 ?

That being said, there might be an architecture agnostic alternative available.
On abort of a RSEQ_CS_FLAG_ABORT_AT_IP critical section, we could let the kernel
decrement/increment the stack pointer to make room for a pointer (depending if the
stack grows down or up). It would then store the abort-at-ip value at the top of
stack.

The abort handler would be expected to use this top of stack abort-at-ip value,
and would be required to increment/decrement (depending on the stack direction)
the stack pointer back to its rightful value before the end of the assembly block.

Thoughts ?

Thanks,

Mathieu

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

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

Powered by blists - more mailing lists