On Tue, 2017-10-03 at 18:14 +0100, Marc Zyngier wrote:
> Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system
> results in the following splat:
>
> [...]
> arm-ccn e8000000.ccn: No access to interrupts, using timer.
> BUG: using smp_processor_id() in preemptible [00000000] code:
> swapper/0/1
> caller is debug_smp_processor_id+0x1c/0x28
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0 #6111
> Hardware name: AMD Seattle/Seattle, BIOS 17:08:23 Jun 26 2017
> Call trace:
> [<ffff000008089e78>] dump_backtrace+0x0/0x278
> [<ffff00000808a22c>] show_stack+0x24/0x30
> [<ffff000008bc3bc4>] dump_stack+0x8c/0xb0
> [<ffff00000852b534>] check_preemption_disabled+0xfc/0x100
> [<ffff00000852b554>] debug_smp_processor_id+0x1c/0x28
> [<ffff000008551bd8>] arm_ccn_probe+0x358/0x4f0
> [...]
>
> as we use smp_processor_id() in the wrong context.
>
> Turn this into a get_cpu()/put_cpu() that extends over the CPU
> hotplug
> registration, making sure that we don't race against a CPU down
> operation.
>
> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com>

Acked-by: Pawel Moll <pawel.m...@arm.com>

I assume you'll get this merged yourself? Or do you want me to relay
the CCN one (I've got a couple of other small changes to the driver in
the queue).

Paweł
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Reply via email to