linux-kernel - Sv: [PATCH] hrtimer: Interrupt storm on clock

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <PH0PR11MB4904A4830FED08F91CA97C04928B9@PH0PR11MB4904.namprd11.prod.outlook.com>
Date:   Fri, 12 Feb 2021 13:38:23 +0000
From:   "Beckius, Mikael" <mikael.beckius@...driver.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     Anna-Maria Behnsen <anna-maria@...utronix.de>
Subject: Sv: [PATCH] hrtimer: Interrupt storm on clock_settime

Thanks for the update and sorry for the late reply. After long-term testing of the patch, storm detection improved, it turns out that a similar problem can occur if hrtimer_interrupt runs during clock_settime. In this case it seems the offset can get updated and later read using hrtimer_update_base in hrtimer_interrupt before softirq_expires_next gets updated. As soon as softirq_expires_next gets updated by hrtimer_force_reprogram the storm ends. To fix this I made the below changes.

--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -529,8 +529,10 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base,
 			if (exclude)
 				continue;

-			if (timer->is_soft)
+			if (timer->is_soft) {
 				cpu_base->softirq_next_timer = timer;
+				cpu_base->softirq_expires_next = expires;
+			}
 			else
 				cpu_base->next_timer = timer;
 		}
@@ -633,19 +635,6 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal)
 	 */
 	expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL);

-	if (cpu_base->next_timer && cpu_base->next_timer->is_soft) {
-		/*
-		 * When the softirq is activated, hrtimer has to be
-		 * programmed with the first hard hrtimer because soft
-		 * timer interrupt could occur too late.
-		 */
-		if (cpu_base->softirq_activated)
-			expires_next = __hrtimer_get_next_event(cpu_base,
-								HRTIMER_ACTIVE_HARD);
-		else
-			cpu_base->softirq_expires_next = expires_next;
-	}
-
 	if (skip_equal && expires_next == cpu_base->expires_next)
 		return;

--

This is similar to hrtimer_reprogram. I also removed the cpu_base->softirq_activated case since as far as I can tell expires_next must be hard if cpu_base->softirq_activated is true. I might be missing something as I don't have whole picture of the hrtimer subsystem but at least no interrupt storms are detected during clock_settime with latest changes.

Micke