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 196AB3A7840 for ; Tue, 24 Feb 2026 16:38:11 +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=1771951091; cv=none; b=iLRgamfkhYJ1A4v/Nf3AhFT0ALm1fRdyp+aWo0spT8iD34fxPhvFAjU+rkIJ6yNaF22hv/eWoYLvs1cGun7wjPTKklLQC6JuqtH1E1CQkV1NnVqcXGQhL3u+VsLt4omNc8br95HQSwQLq93KyrTvN0r+6W7Rl8aNZC33AeAyYrQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771951091; c=relaxed/simple; bh=uCfOfxDrlhrBdfs7rZilyipLgOf8PozhpgbZP530OFM=; h=Date:Message-ID:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=LDgZUpJZLxWkVjtkEwwCaYGUBMU2YQV+Fj3ERjVCTywz9978ayene7K3/C+jYWwbZ95XR/gwOK1MMK5YWxBG8n8M5avF5XChpLc8dhwNlQzzKNsRDqGV+IoBeyxkUfASr5m9v5evQdMWqvK3KlVhNCEpbjlqtF8TqA/k1aBfXj8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ubr++tDY; 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="Ubr++tDY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 696D0C116D0; Tue, 24 Feb 2026 16:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771951091; bh=uCfOfxDrlhrBdfs7rZilyipLgOf8PozhpgbZP530OFM=; h=Date:From:To:Cc:Subject:References:From; b=Ubr++tDYuWMqdbgBWjFGKxWGD3D0vkGwg9k5m0i8o6BlUoGIjvb+Vbo4cWcyVnsIN sRx0+8TwFGVKLWuJKG27HX0YA5ymet7CsanUmOoG68MFypE933XgLq1TXLPQcVhZLq GboTDf/LmIhqdjL1jd5z1g2zicJd1+6vOm1/cHcoeaAh6N21MJjOkUE2NeFO/zkO1i L9EtQ9CVA4IkcCUmNT9fFujbyg3sz49ft4mdqFeHUC7eDCWHqjAOQ8sEdRIQgmX8HS 5S1YGUiGAHRxJXanR33G/b45XRCWndfwcvV6o0tuHnlA8WGOdWrzSMWFBMMx34FsY8 RrGbcfhQvq8eA== Date: Tue, 24 Feb 2026 17:38:07 +0100 Message-ID: <20260224163431.142854488@kernel.org> User-Agent: quilt/0.68 From: Thomas Gleixner To: LKML Cc: Anna-Maria Behnsen , John Stultz , Stephen Boyd , Daniel Lezcano , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , x86@kernel.org, Peter Zijlstra , Frederic Weisbecker , Eric Dumazet Subject: [patch 36/48] softirq: Prepare for deferred hrtimer rearming References: <20260224163022.795809588@kernel.org> 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=UTF-8 From: Peter Zijlstra The hrtimer interrupt expires timers and at the end of the interrupt it rearms the clockevent device for the next expiring timer. That's obviously correct, but in the case that a expired timer sets NEED_RESCHED the return from interrupt ends up in schedule(). If HRTICK is enabled then schedule() will modify the hrtick timer, which causes another reprogramming of the hardware. That can be avoided by deferring the rearming to the return from interrupt path and if the return results in a immediate schedule() invocation then it can be deferred until the end of schedule(), which avoids multiple rearms and re-evaluation of the timer wheel. In case that the return from interrupt ends up handling softirqs before reaching the rearm conditions in the return to user entry code functions, a deferred rearm has to be handled before softirq handling enables interrupts as soft interrupt handling can be long and would therefore introduce hard to diagnose latencies to the timer interrupt. Place the for now empty stub call right before invoking the softirq handling routine. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner --- tglx: Split out to make it simpler to review and to make cross subsystem merge logistics trivial. --- kernel/softirq.c | 15 ++++++++++++++- kernel/softirq.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -663,6 +663,13 @@ void irq_enter_rcu(void) { __irq_enter_raw(); + /* + * If this is a nested interrupt that hits the exit_to_user_mode_loop + * where it has enabled interrupts but before it has hit schedule() we + * could have hrtimers in an undefined state. Fix it up here. + */ + hrtimer_rearm_deferred(); + if (tick_nohz_full_cpu(smp_processor_id()) || (is_idle_task(current) && (irq_count() == HARDIRQ_OFFSET))) tick_irq_enter(); @@ -719,8 +726,14 @@ static inline void __irq_exit_rcu(void) #endif account_hardirq_exit(current); preempt_count_sub(HARDIRQ_OFFSET); - if (!in_interrupt() && local_softirq_pending()) + if (!in_interrupt() && local_softirq_pending()) { + /* + * If we left hrtimers unarmed, make sure to arm them now, + * before enabling interrupts to run SoftIRQ. + */ + hrtimer_rearm_deferred(); invoke_softirq(); + } if (IS_ENABLED(CONFIG_IRQ_FORCED_THREADING) && force_irqthreads() && local_timers_pending_force_th() && !(in_nmi() | in_hardirq()))