From: Peter Zijlstra <peterz@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Mathias Stearn <mathias@mongodb.com>,
Dmitry Vyukov <dvyukov@google.com>,
Jinjie Ruan <ruanjinjie@huawei.com>,
linux-man@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Boqun Feng <boqun.feng@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Chris Kennelly <ckennelly@google.com>,
regressions@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Ingo Molnar <mingo@kernel.org>,
Blake Oler <blake.oler@mongodb.com>
Subject: Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
Date: Fri, 24 Apr 2026 17:03:18 +0200 [thread overview]
Message-ID: <20260424150318.GE641209@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <87v7dgzbo7.ffs@tglx>
On Fri, Apr 24, 2026 at 04:16:08PM +0200, Thomas Gleixner wrote:
> On Fri, Apr 24 2026 at 10:32, Mathias Stearn wrote:
> > On Fri, Apr 24, 2026 at 9:57 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >> The only problem is with membarrier (it used to force write to
> >> __rseq_abi.cpu_id_start for all threads, but now it does not).
> >> Otherwise the caching scheme works.
> >
> > I almost wrote a message last night saying that we didn't need
> > cpu_id_start invalidation on preemption. However, I remembered that
> > the Grow() function[1] does a load outside of a critical section then
> > stores a derived value inside the critical section, guarded only by
> > the cpu_id_start invalidation check in StoreCurrentCpu[2]. It really
> > should be doing a compare against the original value inside the
> > critical section (or just do the whole thing inside), but it doesn't.
> > I haven't reasoned end-to-end through this fully to prove corruption
> > is possible, but I suspect that it is if another thread same-cpu
> > preempts between the loads and the store and updates the header before
> > the original thread resumes and writes its original intended header
> > value. Ditto for signals, which sometimes allocate even though they
> > shouldn't.
> >
> > I was really hoping that we would only need to do the "redundant"
> > cpu_id_start writes would only be needed on membarrier_rseq IPIs where
> > it really is a pay-for-what-you-use functionality,
>
> That's fine and can be solved without adding this sequence overhead into
> the scheduler hotpath.
Something like so? (probably needs help for !GENERIC bits)
---
diff --git a/include/asm-generic/thread_info_tif.h b/include/asm-generic/thread_info_tif.h
index 528e6fc7efe9..1d786003e42a 100644
--- a/include/asm-generic/thread_info_tif.h
+++ b/include/asm-generic/thread_info_tif.h
@@ -48,7 +48,10 @@
#define TIF_RSEQ 11 // Run RSEQ fast path
#define _TIF_RSEQ BIT(TIF_RSEQ)
-#define TIF_HRTIMER_REARM 12 // re-arm the timer
+#define TIF_RSEQ_FORCE_RESTART 12 // Reset RSEQ-CS from membarrier
+#define _TIF_RSEQ_FORCE_RESTART BIT(TIF_RSEQ_FORCE_RESTART)
+
+#define TIF_HRTIMER_REARM 13 // re-arm the timer
#define _TIF_HRTIMER_REARM BIT(TIF_HRTIMER_REARM)
#endif /* _ASM_GENERIC_THREAD_INFO_TIF_H_ */
diff --git a/include/linux/rseq.h b/include/linux/rseq.h
index b9d62fc2140d..2cbee6d41198 100644
--- a/include/linux/rseq.h
+++ b/include/linux/rseq.h
@@ -158,6 +158,8 @@ static inline unsigned int rseq_alloc_align(void)
return 1U << get_count_order(offsetof(struct rseq, end));
}
+extern void rseq_prepare_membarrier(struct mm_struct *mm);
+
#else /* CONFIG_RSEQ */
static inline void rseq_handle_slowpath(struct pt_regs *regs) { }
static inline void rseq_signal_deliver(struct ksignal *ksig, struct pt_regs *regs) { }
@@ -167,6 +169,7 @@ static inline void rseq_force_update(void) { }
static inline void rseq_virt_userspace_exit(void) { }
static inline void rseq_fork(struct task_struct *t, u64 clone_flags) { }
static inline void rseq_execve(struct task_struct *t) { }
+static inline void rseq_prepare_membarrier(struct mm_struct *mm) { }
#endif /* !CONFIG_RSEQ */
#ifdef CONFIG_DEBUG_RSEQ
diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
index f11ebd34f8b9..3dfaca776971 100644
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -686,7 +686,12 @@ static __always_inline bool __rseq_exit_to_user_mode_restart(struct pt_regs *reg
#ifdef CONFIG_HAVE_GENERIC_TIF_BITS
static __always_inline bool test_tif_rseq(unsigned long ti_work)
{
- return ti_work & _TIF_RSEQ;
+ return ti_work & (_TIF_RSEQ | _TIF_RSEQ_FORCE_RESTART);
+}
+
+static __always_inline void clear_tif_rseq_force_restart(void)
+{
+ clear_thread_flag(TIF_RSEQ_FORCE_RESTART);
}
static __always_inline void clear_tif_rseq(void)
@@ -696,6 +701,7 @@ static __always_inline void clear_tif_rseq(void)
}
#else
static __always_inline bool test_tif_rseq(unsigned long ti_work) { return true; }
+static __always_inline void clear_tif_rseq_force_restart(void) { }
static __always_inline void clear_tif_rseq(void) { }
#endif
@@ -703,6 +709,11 @@ static __always_inline bool
rseq_exit_to_user_mode_restart(struct pt_regs *regs, unsigned long ti_work)
{
if (unlikely(test_tif_rseq(ti_work))) {
+ if (unlikely(ti_work & _TIF_RSEQ_FORCE_RESTART)) {
+ current->rseq.event.sched_switch = true;
+ current->rseq.event.ids_changed = true;
+ clear_tif_rseq_force_restart();
+ }
if (unlikely(__rseq_exit_to_user_mode_restart(regs))) {
current->rseq.event.slowpath = true;
set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
diff --git a/kernel/rseq.c b/kernel/rseq.c
index 38d3ef540760..9adc7f63adf5 100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -255,6 +255,19 @@ static bool rseq_handle_cs(struct task_struct *t, struct pt_regs *regs)
return false;
}
+void rseq_prepare_membarrier(struct mm_struct *mm)
+{
+ struct task_struct *t;
+
+ guard(mutex)(&mm->mm_cid.mutex);
+
+ hlist_for_each_entry(t, &mm->mm_cid.user_list, mm_cid.node) {
+ if (t == current)
+ continue;
+ set_tsk_thread_flag(t, TIF_RSEQ_FORCE_RESTART);
+ }
+}
+
static void rseq_slowpath_update_usr(struct pt_regs *regs)
{
/*
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 623445603725..696988bb991b 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -334,6 +334,7 @@ static int membarrier_private_expedited(int flags, int cpu_id)
MEMBARRIER_STATE_PRIVATE_EXPEDITED_RSEQ_READY))
return -EPERM;
ipi_func = ipi_rseq;
+ rseq_prepare_membarrier(mm);
} else {
WARN_ON_ONCE(flags);
if (!(atomic_read(&mm->membarrier_state) &
next prev parent reply other threads:[~2026-04-24 15:03 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 9:50 [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere Mathias Stearn
2026-04-22 12:56 ` Peter Zijlstra
2026-04-22 13:13 ` Peter Zijlstra
2026-04-23 10:38 ` Mathias Stearn
[not found] ` <CAHnCjA2fa+dP1+yCYNQrTXQaW-JdtfMj7wMikwMeeCRg-3NhiA@mail.gmail.com>
2026-04-23 11:48 ` Thomas Gleixner
2026-04-23 12:11 ` Mathias Stearn
2026-04-23 17:19 ` Thomas Gleixner
2026-04-23 17:38 ` Chris Kennelly
2026-04-23 17:47 ` Mathieu Desnoyers
2026-04-23 19:39 ` Thomas Gleixner
2026-04-23 17:41 ` Linus Torvalds
2026-04-23 18:35 ` Mathias Stearn
2026-04-23 18:53 ` Mark Rutland
2026-04-23 21:03 ` Thomas Gleixner
2026-04-23 21:28 ` Linus Torvalds
2026-04-23 23:08 ` Linus Torvalds
2026-04-27 7:06 ` Florian Weimer
2026-04-27 16:12 ` Linus Torvalds
2026-04-22 13:09 ` Mark Rutland
2026-04-22 17:49 ` Thomas Gleixner
2026-04-22 18:11 ` Mark Rutland
2026-04-22 19:47 ` Thomas Gleixner
2026-04-23 1:48 ` Jinjie Ruan
2026-04-23 5:53 ` Dmitry Vyukov
2026-04-23 10:39 ` Thomas Gleixner
2026-04-23 10:51 ` Mathias Stearn
2026-04-23 12:24 ` David Laight
2026-04-23 19:31 ` Thomas Gleixner
2026-04-24 7:56 ` Dmitry Vyukov
2026-04-24 8:32 ` Mathias Stearn
2026-04-24 9:30 ` Dmitry Vyukov
2026-04-24 14:16 ` Thomas Gleixner
2026-04-24 15:03 ` Peter Zijlstra [this message]
2026-04-24 19:44 ` Thomas Gleixner
2026-04-26 22:04 ` Thomas Gleixner
2026-04-27 7:40 ` Florian Weimer
2026-04-27 11:03 ` Thomas Gleixner
2026-04-27 18:35 ` Mathieu Desnoyers
2026-04-27 21:06 ` Thomas Gleixner
2026-04-28 6:11 ` Dmitry Vyukov
2026-04-28 8:07 ` Thomas Gleixner
2026-04-28 8:18 ` Thomas Gleixner
2026-04-28 10:53 ` Dmitry Vyukov
2026-04-28 13:31 ` Mathias Stearn
2026-04-28 15:46 ` Thomas Gleixner
2026-04-28 7:39 ` Peter Zijlstra
2026-04-28 8:13 ` Peter Zijlstra
2026-04-28 8:51 ` Thomas Gleixner
2026-04-28 8:03 ` Peter Zijlstra
2026-04-28 8:36 ` Thomas Gleixner
2026-04-23 12:11 ` Alejandro Colomar
2026-04-23 12:54 ` Mathieu Desnoyers
2026-04-23 12:29 ` Mathieu Desnoyers
2026-04-23 12:36 ` Dmitry Vyukov
2026-04-23 12:53 ` Mathieu Desnoyers
2026-04-23 12:58 ` Dmitry Vyukov
2026-04-24 16:45 ` [PATCH] arm64/entry: Fix arm64-specific rseq brokenness (was: Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64) " Mark Rutland
2026-04-28 1:39 ` [PATCH] arm64/entry: Fix arm64-specific rseq brokenness Jinjie Ruan
2026-04-28 13:40 ` Mark Rutland
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=20260424150318.GE641209@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=blake.oler@mongodb.com \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=ckennelly@google.com \
--cc=dvyukov@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathias@mongodb.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=paulmck@kernel.org \
--cc=regressions@lists.linux.dev \
--cc=ruanjinjie@huawei.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.