Messages in this thread | | | Date | Wed, 10 Feb 2016 11:52:31 +0000 | From | James Morse <> | Subject | Re: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump |
| |
On 10/02/16 10:29, Will Deacon wrote: > On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote: >> dump_backtrace may be called in kthread context, which is not bound to a single >> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug >> report: > > If we're preemptible here, it means that our irq_stack_ptr is potentially > bogus. Whilst this isn't an issue for kthreads, it does feel like we > could make this slightly more robust in the face of potential frame > corruption. Maybe just zero the IRQ stack pointer if we're in preemptible > context?
Switching between stacks is only valid if we are tracing ourselves while on the irq_stack, we should probably prevent it for other tasks too.
Something like (untested): --------------------- if (tsk == current && in_atomic()) irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id()); else irq_stack_ptr = 0; ---------------------
This would work when we trace ourselves while on the irq_stack, but break* tracing a running task on a remote cpu (khungtaskd doesn't do this).
The same fix would apply to unwind_frame(), we have 'tsk' in both functions.
Thoughts?
James
* If this were to ever happen, we would fail to switch to the original stack if tracing a remote irq stack, and print the wrong exception args. I'm not aware of any users of this, (panic() sends an IPI).
| |