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 A4E1E2C0F9C for ; Mon, 2 Feb 2026 23:28:17 +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=1770074897; cv=none; b=QgxdO7jR8q0piWm9rqvQS7p+ZGjF3zvKHmuIJoQFa3b9Y32HCyraw4PgJEQf6bjzPTyAsnK6jpMMHikt9i4x8tTN5sPsnvNtklGxJTbvCTN5huT8yBnjqaaCXfmFpAlHmXUER/t6FeyZC/glytpQ4DT25sL6HKr/1l4PQN47Zro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770074897; c=relaxed/simple; bh=WMjz6mJmmdMZ7Muh/MlZlnIC884Vv0JA++9yUVeioIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=IFB2KYWEFoWIIrTI2eakJIs5kxjGSPzgbRb7ijKPRA+mnffMwHALoa9oQTPr8omPgNP91NOmFODu84JmC3ZFHPpJdPQoHN6uMGpdypY40gaomKmtGhWmC3w37eMbJPlT65/42MtK1HYqlb+B0kzkGgr9dRzCAcjOtKY9f6pNcBY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qDMNjZKJ; 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="qDMNjZKJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 713C6C116C6; Mon, 2 Feb 2026 23:28:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770074897; bh=WMjz6mJmmdMZ7Muh/MlZlnIC884Vv0JA++9yUVeioIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=qDMNjZKJ0gc72Hp1olhCS7ekfnXf/bpJ0gexY7UM/PjUgwwFGE72/r0UrG4zrRnus RGSDLvo2O/0vaWsbhHkGQi2SqEwXA6SEgyBv+Poe3pqqG+n8mE/xF3oythu9G5mhY0 yNWQlYJa/3M1SEf9gfdlLSUDHW9DpFxv1JzP4GnQWH5TiObT5wN0FiPokc4XUIUJpc 1ZZGRVrMS3LfR7fDHHgrjkAOJ63cOvC55nOmgUwEoRXI+ABpz5tC+luYVJfbAFN4+h nkz5g7gsZICLEB3uMMKVlsg6O2QyFGvMuGSJRz6g1xEq3IE1OSgEnojEmPqMfEA5MZ JmSV216m+oLWA== 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: <20260202163355.GI1395266@noisy.programming.kicks-ass.net> References: <20260121162010.647043073@infradead.org> <20260121162508.011240183@infradead.org> <878qdbfbza.ffs@tglx> <20260202163355.GI1395266@noisy.programming.kicks-ass.net> Date: Tue, 03 Feb 2026 00:28:13 +0100 Message-ID: <87v7ge4tf6.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 Mon, Feb 02 2026 at 17:33, Peter Zijlstra wrote: > On Mon, Feb 02, 2026 at 03:37:13PM +0100, Thomas Gleixner wrote: >> On Wed, Jan 21 2026 at 17:20, Peter Zijlstra wrote: >> > while (ti_work & EXIT_TO_USER_MODE_WORK_LOOP) { >> > >> > + /* >> > + * If hrtimer need re-arming, do so before enabling IRQs, >> > + * except when a reschedule is needed, in that case schedule() >> > + * will do this. >> > + */ >> > + if ((ti_work & (_TIF_NEED_RESCHED | >> > + _TIF_NEED_RESCHED_LAZY | >> > + _TIF_HRTIMER_REARM)) == _TIF_HRTIMER_REARM) >> > + hrtimer_rearm(); >> >> Two things I'm not convinced that they are handled correctly: >> >> 1) Interrupts >> >> After reenabling interrupts and before reaching schedule() an >> interrupt comes in and runs soft interrupt processing for a while >> on the way back, which delays the update until that processing >> completes. > > So the basic thing looks like: > > > irqentry_enter() > run_irq_on_irqstack_cond() > if (user_mode() || hardirq_stack_inuse) > irq_enter_rcu(); > func_c(); > irq_exit_rcu() > __irq_exit_rcu() > invoke_softirq() > irqentry_exit() > irqentry_exit_to_user_mode() > irqentry_exit_to_user_mode_prepare() > __exit_to_user_mode_prepare() > exit_to_user_mode_loop() > ...here... > > 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. 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(); } Thanks, tglx