Commit 68b2c8c1 authored Aug 21, 2019 by Julien Grall Committed by Thomas Gleixner Aug 21, 2019

hrtimer: Don't take expiry_lock when timer is currently migrated



migration_base is used as a placeholder when an hrtimer is migrated to a
different CPU. In the case that hrtimer_cancel_wait_running() hits a timer
which is currently migrated it would pointlessly acquire the expiry lock of
the migration base, which is even not initialized.

Surely it could be initialized, but there is absolutely no point in
acquiring this lock because the timer is guaranteed not to run it's
callback for which the caller waits to finish on that base. So it would
just do the inc/lock/dec/unlock dance for nothing.

As the base switch is short and non-preemptible, there is no issue when the
wait function returns immediately.

The timer base and base->cpu_base cannot be NULL in the code path which is
invoking that, so just replace those checks with a check whether base is
migration base.

[ tglx: Updated from RT patch. Massaged changelog. Added comment. ]

Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190821092409.13225-4-julien.grall@arm.com

parent dd2261ed

kernel/time/hrtimer.c

+5 −1

Original line number	Diff line number	Diff line
		@@ -1217,7 +1217,11 @@ void hrtimer_cancel_wait_running(const struct hrtimer *timer)
		/* Lockless read. Prevent the compiler from reloading it below */
		struct hrtimer_clock_base *base = READ_ONCE(timer->base);

		if (!timer->is_soft \|\| !base \|\| !base->cpu_base) {
		/*
		* Just relax if the timer expires in hard interrupt context or if
		* it is currently on the migration base.
		*/
		if (!timer->is_soft \|\| base == &migration_base)
		cpu_relax();
		return;
		}

Admin message