Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1724176

[PATCH 02/25] hrtimer: Correct blantanly wrong comment

From Anna-Maria Gleixner <anna-maria@linutronix.de>
Newsgroups linux.kernel
Subject [PATCH 02/25] hrtimer: Correct blantanly wrong comment
Date 2017-08-31 14:30 +0200
Message-ID <ukwLF-5Ay-35@gated-at.bofh.it> (permalink)
References <ukwLD-5Ay-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


From: Thomas Gleixner <tglx@linutronix.de>

The protection of a hrtimer which runs its callback against migration to a
different CPU has nothing to do with hard interrupt context.

The protection against migration of a hrtimer running the expiry callback
is the pointer in the cpu_base which holds a pointer to the currently
running timer. This pointer is evaluated in the code which potentially
switches the timer base and makes sure it's kept on the CPU on which the
callback is running.

Reported-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
---
 kernel/time/hrtimer.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1204,9 +1204,9 @@ static void __run_hrtimer(struct hrtimer
 		timer->is_rel = false;
 
 	/*
-	 * Because we run timers from hardirq context, there is no chance
-	 * they get migrated to another cpu, therefore its safe to unlock
-	 * the timer base.
+	 * The timer is marked as running in the cpu base, so it is
+	 * protected against migration to a different CPU even if the lock
+	 * is dropped.
 	 */
 	raw_spin_unlock(&cpu_base->lock);
 	trace_hrtimer_expire_entry(timer, now);

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

[PATCH 02/25] hrtimer: Correct blantanly wrong comment Anna-Maria Gleixner <anna-maria@linutronix.de> - 2017-08-31 14:30 +0200

csiph-web