linux-kernel - [PATCH v2] nohz: Fix missing tick reprog while interrupting inline timer softirq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri,  3 Aug 2018 15:31:34 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Anna-Maria Gleixner <anna-maria@...utronix.de>
Subject: [PATCH v2] nohz: Fix missing tick reprog while interrupting inline timer softirq

The full nohz tick is reprogrammed on IRQ exit only if we are not in
a nesting interrupt. This stands as an optimization: whether we are
interrupting a hardirq or a softirq, the tick is going to be
reprogrammed eventually in the end of the inner IRQ, with even potential
new updates on the timer queue.

Now when we are interrupting softirqs, we always assume that they are
executing on IRQ-tail. Indeed 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 IRQ, 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 IRQ-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 us later in userspace with the tick
unprogrammed while we can have timers in the queue.

To fix this, simply keep reprogramming the tick if we are in a hardirq
interrupting softirq. We can still figure out a way later to restore
this optimization while excluding inline softirq processing.

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>
Tested-by: Anna-Maria Gleixner <anna-maria@...utronix.de>
Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...nel.org>
---
 kernel/softirq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/softirq.c b/kernel/softirq.c
index 900dcfe..0980a81 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -386,7 +386,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
-- 
2.7.4