From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 36268305665; Sat, 8 Aug 2026 08:36:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786178213; cv=none; b=WSTFdm/t9a/W6Pu/7ecYkhv/6MbQEKOBOdr86+LAxij3vCDxw13IeDQY4Jl/+m5SXIJm9yQTcvfHrUsaS6b8V7bSnZrDGpF0oig2CTf0LMOxDpuZJYlR/k7jj5sfSL2Swsv8aCEL5SVjY3bmvk85oO7jQXhPzz4XMvPnLsWFwxo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786178213; c=relaxed/simple; bh=XNNCMIIDJ0+U9TcGnveiMM/+DKxXtVRX9/X2JvI0VkQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qF299NpIwZHCSOY7hVPZgioSCTziQwMNl8bRP9iM9ij8ZRRs8M/qOmq3aaTrTq7L6k8dOhira/r+qdNsnG5UEXCYbXykBNDdEQLjqrNDaQYzk73SMzP1LKPyuROc5etCikptDFAJkte4Epfj6n9XESXSqM6Kl5J4R4vWywC19u8= 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=EHsUh0Tj; arc=none smtp.client-ip=90.155.92.199 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="EHsUh0Tj" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=WrzeMuiVEAQBSlmuenq/a74CUSSQoZ4UTPULHvP0oA4=; b=EHsUh0TjchGxSEuIGmKsg6hHNV +S6y86W9pI3ghs2goef5n0HlMn8D499xU+oVD3hJOgab6m9j+vkBmqcWK3YhdYy1A048CWnHWrm3z ISGACNXEUHUrTwcRpZ58P3yLD8jY4u3YW/yIKrLccmcy/WeChKCbOLDcfz5/q89bJiLj4ib094yle Ju7Ncd894ySn5OpdA8JTd1OYVOSlFa7JN532h2Bhi420dRXBh1eUgXP9OTW34tP99ANUrJgcbxqQI nVDWUiPl8n+jEW+RU3tk4pF3XHwdZEu+85XY/ILyUBHO8Qgzk8c/EIhhuqGPCvKMr2t5wPemPrPfj I8+eqaPw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wscXl-0000000CrZ5-0dR5; Sat, 08 Aug 2026 08:36:38 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id CCD39300182; Sat, 08 Aug 2026 10:36:35 +0200 (CEST) Date: Sat, 8 Aug 2026 10:36:35 +0200 From: Peter Zijlstra To: Thomas Gleixner Cc: tip-bot2 for Niels Pressel , linux-tip-commits@vger.kernel.org, Niels Pressel , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [tip: core/urgent] entry/rseq: Fix hard lockup on granted time slice extension Message-ID: <20260808083635.GR687043@noisy.programming.kicks-ass.net> References: <20260806113429.38333-1-npressel@ethz.ch> <178602048581.708.11608729612787939146.tip-bot2@tip-bot2> <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; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y0ehmy3c.ffs@fw13> On Fri, Aug 07, 2026 at 11:15:19PM +0200, Thomas Gleixner wrote: > > @@ -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. Well, you can do user access with IRQs disabled just fine, you just get more efault. But yes, this one really wants the fault handler to page in stuff if it is so needed.. Moo :-( > 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. Bah, its spread out over too damn many functions is what :/ Anyway, I see you've not yet pulled the patch, let me go do that now.