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).