[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87tt1yw76g.ffs@tglx>
Date: Sat, 23 Aug 2025 14:31:35 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, LKML
<linux-kernel@...r.kernel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, "Paul E. McKenney"
<paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>
Subject: Re: [PATCH] rseq: Protect event mask against membarrier IPI
On Wed, Aug 20 2025 at 09:23, Mathieu Desnoyers wrote:
> On 2025-08-13 11:02, Thomas Gleixner wrote:
> We should also update this comment in include/linux/sched.h:
>
> /*
> * RmW on rseq_event_mask must be performed atomically
> * with respect to preemption.
> */
> unsigned long rseq_event_mask;
>
> to e.g.:
>
> /*
> * RmW on rseq_event_mask must be performed atomically
> * with respect to preemption and membarrier IPIs.
> */
True.
>> +
>> /*
>> * Map the event mask on the user-space ABI enum rseq_cs_flags
>> * for direct mask checks.
>> @@ -41,9 +47,8 @@ static inline void rseq_handle_notify_re
>> static inline void rseq_signal_deliver(struct ksignal *ksig,
>> struct pt_regs *regs)
>> {
>> - preempt_disable();
>> - __set_bit(RSEQ_EVENT_SIGNAL_BIT, ¤t->rseq_event_mask);
>> - preempt_enable();
>> + scoped_guard(RSEQ_EVENT_GUARD)
>> + __set_bit(RSEQ_EVENT_SIGNAL_BIT, ¤t->rseq_event_mask);
>
> Then we have more to worry about interaction of the following
> rseq events with membarrier IPI:
>
> - rseq_preempt, rseq_migrate, rseq_signal_deliver.
>
> Both rseq_preempt and rseq_migrate are documented as only being required
> to be called with preempt off, not irq off.
They are always invoked from the middle of the scheduler with interrupts
disabled, so just the documentation is wrong.
> Can we just move the event sources requiring preempt-off to their own
> word, and use a separate word for membarrier IPI instead ? This would
> allow us to partition the problem into two distinct states each
> protected by their respective mechanism.
signal delivery can just use set_bit() which is atomic vs. the IPI no?
But as I pointed out in the other series, we don't need that whole zoo
of event bits at all. There is absolutely no point.
signal delivery does not need to set an event in the first place. It can
just unconditionally invoke this stuff, no?
Thanks,
tglx
Powered by blists - more mailing lists