From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B8838394467 for ; Tue, 3 Feb 2026 08:14:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770106484; cv=none; b=Pc3pygaRMag5fM2COmUYARVkBstBO104b5XxczEB3aUKIw8tXdJoUPnTfs0VWyCL+IWkgUPjXfuzKEFJyCOvBXaqNWwuqXxxA1j6CzY3peoQN2LTqurVtSzCvzOfvpChq1/gHqDullkcl/tseVwMzNWyqse/sVj1thdGLBcN1H0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770106484; c=relaxed/simple; bh=TiawticTPFt9jaXtvwQw/fGuDRNXMS8G0DLqcOY8hi4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hv6clTQYlHt8G3C2imHnatWc+YAkk9JnjML77XCVQU/HCJjfMNcD6YrsBxJYFkJGlveMVMpN852cvfEm/GK3xj1wGAIse2EwA1WvXF/18AfThQvjScNud6KjfJ2jl1aXTCklPqjZ/pMQaBmKR5iwZjPUG3Foa47QzQvEi/34j1s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mODl2HWk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mODl2HWk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83D1CC116D0; Tue, 3 Feb 2026 08:14:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770106484; bh=TiawticTPFt9jaXtvwQw/fGuDRNXMS8G0DLqcOY8hi4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mODl2HWku6k6YsQ7JSvPgnmBMeM8yB8vIRX+232S1VyT7SGMQQImpQiIm191HDz+c 31cV+hS4bcMGfrTUlNFKuXANXwbRWPKz9dOGtTgPpnAcFQg5czsZvrJYGpsatNucBB xOVmX5FMzpsM32jStZqSVOvY6BlIS726zXB2ZBVEN88r4jLDl4j10FoIze7lsAmF3E 0/hVSV56sTW+XdIJZUK02Rgg7J6ZeRW1CbgoUPCRt6GpcEdniOFKtwtimmngP80n3r wfblfbNJA7UjkVzbFP/M4j9J/aTu+2EpnIAC/GgzV1D9DMg0uuUlgpB1lmUOI+3X6s LmII07dPkC6gw== From: Thomas Gleixner To: Peter Zijlstra Cc: arnd@arndb.de, anna-maria@linutronix.de, frederic@kernel.org, luto@kernel.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, linux-kernel@vger.kernel.org, oliver.sang@intel.com Subject: Re: [PATCH v2 5/6] entry,hrtimer: Push reprogramming timers into the interrupt return path In-Reply-To: <87v7ge4tf6.ffs@tglx> References: <20260121162010.647043073@infradead.org> <20260121162508.011240183@infradead.org> <878qdbfbza.ffs@tglx> <20260202163355.GI1395266@noisy.programming.kicks-ass.net> <87v7ge4tf6.ffs@tglx> Date: Tue, 03 Feb 2026 09:14:40 +0100 Message-ID: <87pl6m451r.ffs@tglx> 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 Tue, Feb 03 2026 at 00:28, Thomas Gleixner wrote: > On Mon, Feb 02 2026 at 17:33, Peter Zijlstra wrote: >> So a nested IRQ at this point will have !user_mode(), but I think it can >> still end up in softirqs due to that hardirq_stack_inuse. Should we >> perhaps make sure only user_mode() ends up in softirqs? > > All interrupts independent of the mode they hit are ending up in > irq_exit_rcu() and therefore in __irq_exit_rcu() > > run_irq_on_irqstack_cond() > if (user_mode() || hardirq_stack_inuse) > // Stay on user or hardirq stack > irq_enter_rcu(); > func_c(); > irq_exit_rcu() > else > // MAGIC ASM to switch to hardirq stack > call irq_enter_rcu > call func_c > call irq_exit_rcu > > The only reason why invoke_softirq() won't be called is when the > interrupt hits into the softirq processing region of the previous > interrupt, which means it's already on the hardirq stack. In the case I pointed out where the second interrupt hits right after exit to user enabled interupts, there is no nesting and it will happily take the second path which switches to the hardirq stack and then on return processes soft interrupts. > But looking at this there is already a problem without interrupt > nesting: > > irq_enter_rcu(); > timer_interrupt() > hrtimer_interrupt() > delay_rearm(); > irq_exit_rcu() > __irq_exit_rcu() > invoke_softirq() <- Here > > Soft interrupts can run for quite some time, which means this already > can cause timers being delayed for way too long. I think in > __irq_exit_rcu() you want to do: > > if (!in_interrupt() && local_softirq_pending()) { > hrtimer_rearm(); > invoke_softirq(); > } Actually it's worse. Assume the CPU on which this happens has the jiffies duty. As the timer does not fire, jiffies become stale. So anything which relies on jiffies going forward will get stuck until some other condition breaks the tie. That's going to be fun to debug :) Thanks, tglx