From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12A00327C0D for ; Mon, 3 Aug 2026 07:19:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785741594; cv=none; b=uCFNOEyJsz/OIp51fmn7Ym5V17fxQo/HIDJEsqxkNIqA6z1yy4s0GPkNeUdNFubz2A+TtXySkIH0pPMCXPPjGYfjKFtGqe9KQsBXyNu1JewDCyhfGoKywCxa7iMfn+Nq0Ls6ifwyQc5X2nEXyktWxo1H9q0/yfNdlBPa12m2ICw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785741594; c=relaxed/simple; bh=0pem9aQyy1QOr/nAyai4zUkaHKeTgxlHKnIe1tRC7yE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YbMQioXzgTWjpX+Wzuut1EDuBqV78ooiIELMI/sIxBAC0UxhSazuCqGH404FQ/btZmqVl/Emt8WSNxSuAotGKMKX9vqXaVapSl/85MqxjoA7ZmwVI1PLEDVv5mOSGSwL3eMqzjVsyT8c6v46p3b70DFlpbTBdMnJIihVu4PjWbA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=FsBcVbnS; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="FsBcVbnS" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=29ccDw1RZRPNaV7Ke1MNN893Rq5VMLia3a+7U/6xIcw=; b=FsBcVbnSD286UVgRiuFkSHQPtZ mWWfNa1q/+I1wcilG2JzyhSNiqaEdk56tw1MWMESuixby1pJldZNcdDtp+i7wI1ujZbHsLgn+XvEd lvZ6K0+imUInfwdvR1C7R40bXmgu0bo8T1FiRQnU5o4WdHLPxvYdx7MpgFN2A4S3HrysTD5AT3H9D E2DzY6jZnR6X5pWQ+PWJtJ5YuRnAhI2SI4yzO9ibVe/4dhCjcuHKF1auCPwfseMFVW+6KTAO4cHpD k6VX7gKEEcUQcj9wGe4nt1VJJH0uyVC8G8Uj2I9Jl9SNRkBb0VIQHVPApcaz6fUlXYnMnAA30vb2T HbJ2wJaA==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wqmxa-000000093su-28L9; Mon, 03 Aug 2026 07:19:42 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 1816530045A; Mon, 03 Aug 2026 09:19:40 +0200 (CEST) Date: Mon, 3 Aug 2026 09:19:40 +0200 From: Peter Zijlstra To: Niels Pressel , Thomas Gleixner Cc: Mathieu Desnoyers , "Paul E . McKenney" , Boqun Feng , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] rseq: fix hard lockup on granted time slice extension Message-ID: <20260803071940.GX49951@noisy.programming.kicks-ass.net> References: <20260802124423.51616-1-npressel@ethz.ch> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > --- > 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)