Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
architected timers causes a slew of "using smp_processor_id() in
preemptible" warnings:
BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
caller is arch_timer_cpu_notify+0x14/0xc8
This happens because sometimes the cpu notifier,
arch_timer_cpu_notify(), is called in preemptible context and
other times in non-preemptible context but we use this_cpu_ptr()
to retrieve the clockevent in all cases. We're only going to
actually use the pointer in non-preemptible context though, so
push the this_cpu_ptr() access down into the cases to force the
checks to occur only in non-preemptible contexts.
Cc: Mark Rutland <[email protected]>
Cc: Marc Zyngier <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
---
Changes since v1:
* Pushed down this_cpu_ptr and added a comment
drivers/clocksource/arm_arch_timer.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index d7ad425..a65a710 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct clock_event_device *clk)
static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
{
- struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
-
+ /*
+ * Grab cpu pointer in each case to avoid spurious
+ * preemptible warnings
+ */
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_STARTING:
- arch_timer_setup(evt);
+ arch_timer_setup(this_cpu_ptr(arch_timer_evt));
break;
case CPU_DYING:
- arch_timer_stop(evt);
+ arch_timer_stop(this_cpu_ptr(arch_timer_evt));
break;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
On Fri, 5 Apr 2013 13:57:29 -0700, Stephen Boyd <[email protected]>
wrote:
> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
> architected timers causes a slew of "using smp_processor_id() in
> preemptible" warnings:
>
> BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
> caller is arch_timer_cpu_notify+0x14/0xc8
>
> This happens because sometimes the cpu notifier,
> arch_timer_cpu_notify(), is called in preemptible context and
> other times in non-preemptible context but we use this_cpu_ptr()
> to retrieve the clockevent in all cases. We're only going to
> actually use the pointer in non-preemptible context though, so
> push the this_cpu_ptr() access down into the cases to force the
> checks to occur only in non-preemptible contexts.
>
> Cc: Mark Rutland <[email protected]>
> Cc: Marc Zyngier <[email protected]>
> Signed-off-by: Stephen Boyd <[email protected]>
> ---
>
> Changes since v1:
> * Pushed down this_cpu_ptr and added a comment
>
> drivers/clocksource/arm_arch_timer.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index d7ad425..a65a710 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct
> clock_event_device *clk)
> static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
> unsigned long action, void *hcpu)
> {
> - struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
> -
> + /*
> + * Grab cpu pointer in each case to avoid spurious
> + * preemptible warnings
> + */
> switch (action & ~CPU_TASKS_FROZEN) {
> case CPU_STARTING:
> - arch_timer_setup(evt);
> + arch_timer_setup(this_cpu_ptr(arch_timer_evt));
> break;
> case CPU_DYING:
> - arch_timer_stop(evt);
> + arch_timer_stop(this_cpu_ptr(arch_timer_evt));
> break;
> }
Looks good to me.
Acked-by: Marc Zyngier <[email protected]>
Cheers,
M.
--
Fast, cheap, reliable. Pick two.
On 04/06/13 03:41, Marc Zyngier wrote:
> On Fri, 5 Apr 2013 13:57:29 -0700, Stephen Boyd <[email protected]>
> wrote:
>> Hot-plugging with CONFIG_DEBUG_PREEMPT=y on a device with arm
>> architected timers causes a slew of "using smp_processor_id() in
>> preemptible" warnings:
>>
>> BUG: using smp_processor_id() in preemptible [00000000] code: sh/111
>> caller is arch_timer_cpu_notify+0x14/0xc8
>>
>> This happens because sometimes the cpu notifier,
>> arch_timer_cpu_notify(), is called in preemptible context and
>> other times in non-preemptible context but we use this_cpu_ptr()
>> to retrieve the clockevent in all cases. We're only going to
>> actually use the pointer in non-preemptible context though, so
>> push the this_cpu_ptr() access down into the cases to force the
>> checks to occur only in non-preemptible contexts.
>>
>> Cc: Mark Rutland <[email protected]>
>> Cc: Marc Zyngier <[email protected]>
>> Signed-off-by: Stephen Boyd <[email protected]>
>> ---
>>
>> Changes since v1:
>> * Pushed down this_cpu_ptr and added a comment
>>
>> drivers/clocksource/arm_arch_timer.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index d7ad425..a65a710 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -248,14 +248,16 @@ static void __cpuinit arch_timer_stop(struct
>> clock_event_device *clk)
>> static int __cpuinit arch_timer_cpu_notify(struct notifier_block *self,
>> unsigned long action, void *hcpu)
>> {
>> - struct clock_event_device *evt = this_cpu_ptr(arch_timer_evt);
>> -
>> + /*
>> + * Grab cpu pointer in each case to avoid spurious
>> + * preemptible warnings
>> + */
>> switch (action & ~CPU_TASKS_FROZEN) {
>> case CPU_STARTING:
>> - arch_timer_setup(evt);
>> + arch_timer_setup(this_cpu_ptr(arch_timer_evt));
>> break;
>> case CPU_DYING:
>> - arch_timer_stop(evt);
>> + arch_timer_stop(this_cpu_ptr(arch_timer_evt));
>> break;
>> }
> Looks good to me.
>
> Acked-by: Marc Zyngier <[email protected]>
>
Thanks Marc.
Thomas/John, can you pick this up for 3.10?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation