Messages in this thread Patch in this message | | | From | Sudeep Holla <> | Subject | [PATCH] tick: prefer a lower rating device only if it's CPU local device | Date | Wed, 9 May 2018 17:02:08 +0100 |
| |
Checking the equality of cpumask for both new and old tick device doesn't ensure that it's CPU local device. This will cause issue if a low rating clockevent tick device is registered first followed by the registration of higher rating clockevent tick device.
In such case, clockevents_released list will never get emptied as both the devices get selected as preferred one and we will loop forever in clockevents_notify_released.
Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- kernel/time/tick-common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Hi Thomas,
I am seeing this issue on my Juno devboard, where system wide timers with rating 300 and 400 are registered in same order and we get stuck in a loop in clockevents_notify_released. Let me know if this looks sane or you have any suggestions that I can try out.
Regards, Sudeep
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 49edc1c4f3e6..78e598334007 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -277,7 +277,8 @@ static bool tick_check_preferred(struct clock_event_device *curdev, */ return !curdev || newdev->rating > curdev->rating || - !cpumask_equal(curdev->cpumask, newdev->cpumask); + (!cpumask_equal(curdev->cpumask, newdev->cpumask) && + !tick_check_percpu(curdev, newdev, smp_processor_id())); }
/* -- 2.7.4
| |