From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 D4A5A446064; Fri, 7 Aug 2026 21:15:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786137325; cv=none; b=fFMFFktcwGvumPy8mEijV+Xm6habIdk9E4LbE/1yGVmn5dLeuSY0I8NnYergrEl2gwhu1ezElevWmrGj+1lxpJv5FLGnU27WgHOBI4eD3SRbe+9DlL2RKsFpkK9FI0G4sFRJUQLBbtZDID1L0TanyVy2sKWPnvcUU0MWg5CPGYU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786137325; c=relaxed/simple; bh=l7oIpHHDlbJPwL9zPpQHf3ilZBlp8cP0t0mruBHyFic=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Ho8fyivYtT8cBb/jroXxhwC+Aiua8wwlNMDtfX+busX6OI08XDznpsRh57RgrNZzoBSSpeNPfhVCSV3ylXhuqEJ36KQU2ll3EFIg9YFQkLbQ5I9HvV60/1xvV/XmcGBHIkkqoX9JSrp3UvFPVGPFpKQhsWfOJb+oim0q8aPMu28= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=qWgW3wna; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=iUKFTnUb; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="qWgW3wna"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="iUKFTnUb" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1786137319; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lZh7ivF1opINHoSA1HW5adck64G03AfcjlF0830i0Pw=; b=qWgW3wnaGiIQDchn4UrpwbBk1SYYoijulwvixujG/+pXnKyC9HSZmBzEyHv1xVG1Sxx8Ha 4zsAejUSjMOOqKKihmzIKH4Tur5Tn8w0/bshy9iEGrajmVzCyTi3lpbuQYBkfOxfZuz1om CvYutDA8BRxSwwc1ubeqXr5nsQ3OA0t4fK/IT2SYDjB9OZYqW0as9HjXIUP5mbta4xq2s+ zvALo/GYETceRTfdtBiFPxVWX60bi4ss5fpv8eiqy+B+OMkM6wvjDFzxpg9mLA7y9tUgqv 1dZZZ4Mx7XFcgO0uMgJkgqNUyaliLVXMHaxVqxCqJwM+tILimnXO/mQJ8I1MHg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1786137319; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lZh7ivF1opINHoSA1HW5adck64G03AfcjlF0830i0Pw=; b=iUKFTnUb+HFHrfsgbdezyD99Mdoy/nD77dptnWrc/uddaMmCPrHlen9vBw6K8UG5eyZ8o+ mxdEVa0SRp8dwlCg== To: tip-bot2 for Niels Pressel , linux-tip-commits@vger.kernel.org Cc: Niels Pressel , "Peter Zijlstra (Intel)" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [tip: core/urgent] entry/rseq: Fix hard lockup on granted time slice extension In-Reply-To: <178602048581.708.11608729612787939146.tip-bot2@tip-bot2> References: <20260806113429.38333-1-npressel@ethz.ch> <178602048581.708.11608729612787939146.tip-bot2@tip-bot2> Date: Fri, 07 Aug 2026 23:15:19 +0200 Message-ID: <87y0ehmy3c.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Thu, Aug 06 2026 at 12:48, tip-bot 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). Groan. Can people please use proper words and not random made up acronyms. This is not a SMS service. And this file reference is more than pointless. > Following the suggestion from Peter Zijlstra, fix this potential lockup > by reflowing __exit_to_user_mode_loop() to only enable IRQs after the > TSE check. Which is broken. > @@ -132,6 +132,8 @@ static __always_inline bool __rseq_grant_slice_extension(bool work_pending) > union rseq_slice_state state; > struct rseq __user *rseq; > > + lockdep_assert_irqs_disabled(); > + > if (!rseq_slice_extension_enabled()) > return false; Care to look what the code there does? rseq = curr->rseq.usrptr; scoped_user_rw_access(rseq, efault) { That's user access which requires interrupts to be enabled. Niels' original patch was correct. To answer Peter's question from the V1 submission: >> 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. Yes, but then we consolidated all the schedule() hrtimer interaction and got a benefit when schedule() was invoked directly on the way out. That's why we ended up moving into into the success path of rseq_grant_slice_extension() because that obviously skips schedule(). That's why we have hrtimer_rearm_deferred_user_irq() in __exit_to_user_mode_prepare() _before_ invoking exit_to_user_mode_loop() to ensure that one of the TIF_NEED_RESCHED bits is set. If not and if TIF_HRTIMER_REARM is set, then the rearming happens right there with interrupts still disabled. If one of the TIF_NEED_RESCHED bits is set, then enabling interrupts right on top of the loop is safe because any interrupt/exception entry needs to check the bit as well. So the thing [wm]e f*cked up royally was to invoke hrtimer_rearm_deferred_tif() with interrupts enabled and that needs to be fixed. Of course all of this can be figured out from the copious amount of comments which got added to explain all of this magic. Thanks, tglx