linux-kernel - hrtimer: timeout too long when using HRTIMER_CB

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

Message-Id: <200804251914.m3PJE61B001189@plim.pdb.fsc.net>
Date:	Fri, 25 Apr 2008 21:14:06 +0200
From:	bstroesser@...itsu-siemens.com
To:	linux-kernel@...r.kernel.org
Cc:	bstroesser@...itsu-siemens.com
Subject: hrtimer: timeout too long when using HRTIMER_CB_SOFTIRQ

There seems to be a bug in hrtimer, when callback is handled
in softirq. Sometimes clockevent is missing, so timers are
defered. The patch is for 2.5.22.5, but the problem seems to
persist in 2.6.25.

Please CC me, I'm not on the list.

Best regards
Bodo


============================================================
When using hrtimer with timer->cb_mode == HRTIMER_CB_SOFTIRQ
in some cases the clockevent is not programmed.
This happens, if:
 - a timer is rearmed while it's state is HRTIMER_STATE_CALLBACK
 - hrtimer_reprogram() returns -ETIME, when it is called after
   CALLBACK is finished. This occurs if the new timer->expires
   is in the past when CALLBACK is done.
In this case, the timer needs to be removed from the tree and put
onto the pending list again.

The patch is against 2.6.22.5, but AFAICS, it is relevant
for 2.6.25 also (in run_hrtimer_pending()).

Signed-off-by: Bodo Stroesser <bstroesser@...itsu-siemens.com>
---
 kernel/hrtimer.c |   15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

Index: linux-2.6.22.5-31/kernel/hrtimer.c
===================================================================
--- linux-2.6.22.5-31.orig/kernel/hrtimer.c
+++ linux-2.6.22.5-31/kernel/hrtimer.c
@@ -1124,8 +1124,19 @@ static void run_hrtimer_softirq(struct s
 			 * If the timer was rearmed on another CPU, reprogram
 			 * the event device.
 			 */
-			if (timer->base->first == &timer->node)
-				hrtimer_reprogram(timer, timer->base);
+			struct hrtimer_clock_base *base = timer->base;
+
+			if (base->first == &timer->node &&
+			    hrtimer_reprogram(timer, base)) {
+				/*
+				 * Timer is expired. Thus move it from tree to
+				 * pending list again.
+				 */
+				__remove_hrtimer(timer, base,
+						 HRTIMER_STATE_PENDING, 0);
+				list_add_tail(&timer->cb_entry,
+					      &base->cpu_base->cb_pending);
+			}
 		}
 	}
 	spin_unlock_irq(&cpu_base->lock);