From: Thomas Gleixner <tglx@linutronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
LKML <linux-kernel@vger.kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [PATCH] rseq: Protect event mask against membarrier IPI
Date: Sat, 23 Aug 2025 14:31:35 +0200 [thread overview]
Message-ID: <87tt1yw76g.ffs@tglx> (raw)
In-Reply-To: <a2f916f1-0693-41aa-be72-465d84da5123@efficios.com>
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
next prev parent reply other threads:[~2025-08-23 12:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 15:02 [PATCH] rseq: Protect event mask against membarrier IPI Thomas Gleixner
2025-08-13 16:11 ` Boqun Feng
2025-08-13 16:14 ` Mathieu Desnoyers
2025-08-20 13:23 ` Mathieu Desnoyers
2025-08-23 12:31 ` Thomas Gleixner [this message]
2025-08-25 14:13 ` Mathieu Desnoyers
2025-09-13 17:57 ` [tip: core/rseq] " tip-bot2 for Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tt1yw76g.ffs@tglx \
--to=tglx@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox