All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Niels Pressel <npressel@ethz.ch>, Thomas Gleixner <tglx@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Boqun Feng <boqun@kernel.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] rseq: fix hard lockup on granted time slice extension
Date: Mon, 3 Aug 2026 09:19:40 +0200	[thread overview]
Message-ID: <20260803071940.GX49951@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260802124423.51616-1-npressel@ethz.ch>

On Sun, Aug 02, 2026 at 02:44:23PM +0200, Niels Pressel wrote:
> In __exit_to_user_mode_loop, TSE eligibility is checked while
> IRQs are enabled. Granting a TSE might involve rearming the
> hrtimers. However, hrtimer_rearm_deferred_tif is expected to be
> called with IRQs disabled (see include/linux/hrtimer_rearm.h:17).
> 
> Calling the function with IRQs enabled can lead to a hard lockup
> because __hrtimer_rearm_deferred acquires a raw spinlock (without
> disabling IRQs) that is also acquired in hard IRQ context within
> hrtimer_run_queues.
> 
> Lockdep flags the issue when running the rseq selftests on the
> 7.2-rc5 release:

> 
> Originally, the issue was discovered because of intermittent lockups
> when heavily using rseq TSEs.
> 
> Fix this potential lockup by disabling IRQs around the timer rearm function
> call. Tested the fix using the rseq selftests.
> 
> Fixes: 15dd3a948855 ("hrtimer: Push reprogramming timers into the interrupt return path")
> Signed-off-by: Niels Pressel <npressel@ethz.ch>
> ---
>  include/linux/rseq_entry.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
> index ed9da6e41a2a..31ce349ed42c 100644
> --- a/include/linux/rseq_entry.h
> +++ b/include/linux/rseq_entry.h
> @@ -233,6 +233,7 @@ static __always_inline bool __rseq_grant_slice_extension(bool work_pending)
>  static __always_inline bool rseq_grant_slice_extension(unsigned long ti_work, unsigned long mask)
>  {
>  	if (unlikely(__rseq_grant_slice_extension(ti_work & mask))) {
> +		guard(irq)();
>  		hrtimer_rearm_deferred_tif(ti_work);
>  		return true;
>  	}

Argh!

Thomas, previously we would call hrtimer_rearm_deferred() before
re-enabling IRQs, but here it slipped past. And while disabling it will
cure the splat, I'm thinking it makes sense to reflow
__exit_to_user_mode_loop() to instead delay enabling IRQs.

Something a little like the below, but let me go find more wake-up juice
and double check.

---
 kernel/entry/common.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/kernel/entry/common.c b/kernel/entry/common.c
index e3d381fd3d25..f8c9216cbcea 100644
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -48,11 +48,12 @@ static __always_inline unsigned long __exit_to_user_mode_loop(struct pt_regs *re
 	 */
 	while (ti_work & EXIT_TO_USER_MODE_WORK_LOOP) {
 
-		local_irq_enable();
-
-		if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY)) {
-			if (!rseq_grant_slice_extension(ti_work, TIF_SLICE_EXT_DENY))
-				schedule();
+		if ((ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY)) &&
+		    (!rseq_grant_slice_extension(ti_work, TIF_SLICE_EXT_DENY))) {
+			local_irq_enable();
+			schedule();
+		} else {
+			local_irq_enable();
 		}
 
 		if (ti_work & _TIF_UPROBE)

  reply	other threads:[~2026-08-03  7:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 12:44 [PATCH] rseq: fix hard lockup on granted time slice extension Niels Pressel
2026-08-03  7:19 ` Peter Zijlstra [this message]
2026-08-04  9:35   ` Niels Pressel
2026-08-10  7:41 ` [tip: core/urgent] rseq: Prevent " tip-bot2 for Niels Pressel

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=20260803071940.GX49951@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=boqun@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=npressel@ethz.ch \
    --cc=paulmck@kernel.org \
    --cc=tglx@kernel.org \
    --cc=x86@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.