[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1525881728-4858-1-git-send-email-sudeep.holla@arm.com>
Date: Wed, 9 May 2018 17:02:08 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Cc: Sudeep Holla <sudeep.holla@....com>,
Frederic Weisbecker <fweisbec@...il.com>
Subject: [PATCH] tick: prefer a lower rating device only if it's CPU local device
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@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@....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
Powered by blists - more mailing lists