[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <tip-0a0e0829f990120cef165bbb804237f400953ec2@git.kernel.org>
Date: Fri, 3 Aug 2018 06:54:52 -0700
From: tip-bot for Frederic Weisbecker <tipbot@...or.com>
To: linux-tip-commits@...r.kernel.org
Cc: mingo@...nel.org, tglx@...utronix.de, hpa@...or.com,
linux-kernel@...r.kernel.org, frederic@...nel.org,
anna-maria@...utronix.de
Subject: [tip:timers/urgent] nohz: Fix missing tick reprogram when
interrupting an inline softirq
Commit-ID: 0a0e0829f990120cef165bbb804237f400953ec2
Gitweb: https://git.kernel.org/tip/0a0e0829f990120cef165bbb804237f400953ec2
Author: Frederic Weisbecker <frederic@...nel.org>
AuthorDate: Fri, 3 Aug 2018 15:31:34 +0200
Committer: Thomas Gleixner <tglx@...utronix.de>
CommitDate: Fri, 3 Aug 2018 15:52:10 +0200
nohz: Fix missing tick reprogram when interrupting an inline softirq
The full nohz tick is reprogrammed in irq_exit() only if the exit is not in
a nesting interrupt. This stands as an optimization: whether a hardirq or a
softirq is interrupted, the tick is going to be reprogrammed when necessary
at the end of the inner interrupt, with even potential new updates on the
timer queue.
When soft interrupts are interrupted, it's assumed that they are executing
on the tail of an interrupt return. In that case tick_nohz_irq_exit() is
called after softirq processing to take care of the tick reprogramming.
But the assumption is wrong: softirqs can be processed inline as well, ie:
outside of an interrupt, like in a call to local_bh_enable() or from
ksoftirqd.
Inline softirqs don't reprogram the tick once they are done, as opposed to
interrupt tail softirq processing. So if a tick interrupts an inline
softirq processing, the next timer will neither be reprogrammed from the
interrupting tick's irq_exit() nor after the interrupted softirq
processing. This situation may leave the tick unprogrammed while timers are
armed.
To fix this, simply keep reprogramming the tick even if a softirq has been
interrupted. That can be optimized further, but for now correctness is more
important.
Note that new timers enqueued in nohz_full mode after a softirq gets
interrupted will still be handled just fine through self-IPIs triggered by
the timer code.
Reported-by: Anna-Maria Gleixner <anna-maria@...utronix.de>
Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Tested-by: Anna-Maria Gleixner <anna-maria@...utronix.de>
Cc: stable@...r.kernel.org # 4.14+
Link: https://lkml.kernel.org/r/1533303094-15855-1-git-send-email-frederic@kernel.org
---
kernel/softirq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 75ffc1d1a2e0..6f584861d329 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -390,7 +390,7 @@ static inline void tick_irq_exit(void)
/* Make sure that timer wheel updates are propagated */
if ((idle_cpu(cpu) && !need_resched()) || tick_nohz_full_cpu(cpu)) {
- if (!in_interrupt())
+ if (!in_irq())
tick_nohz_irq_exit();
}
#endif
Powered by blists - more mailing lists