Re: [PATCH v2 1/1] powerpc/crash: Use NMI context for printk when starting to crash

2020-06-08 Thread Michael Ellerman
On Tue, 12 May 2020 18:45:35 -0300, Leonardo Bras wrote: > Currently, if printk lock (logbuf_lock) is held by other thread during > crash, there is a chance of deadlocking the crash on next printk, and > blocking a possibly desired kdump. > > At the start of default_machine_crash_shutdown, make

Re: [PATCH v2 1/1] powerpc/crash: Use NMI context for printk when starting to crash

2020-05-12 Thread Leonardo Bras
Hello Nick, thanks for your feedback. Comments inline: On Wed, 2020-05-13 at 14:36 +1000, Nicholas Piggin wrote: > Excerpts from Leonardo Bras's message of May 13, 2020 7:45 am: > > Currently, if printk lock (logbuf_lock) is held by other thread during > > crash, there is a chance of deadlocking

Re: [PATCH v2 1/1] powerpc/crash: Use NMI context for printk when starting to crash

2020-05-12 Thread Nicholas Piggin
Excerpts from Leonardo Bras's message of May 13, 2020 7:45 am: > Currently, if printk lock (logbuf_lock) is held by other thread during > crash, there is a chance of deadlocking the crash on next printk, and > blocking a possibly desired kdump. > > At the start of default_machine_crash_shutdown,

[PATCH v2 1/1] powerpc/crash: Use NMI context for printk when starting to crash

2020-05-12 Thread Leonardo Bras
Currently, if printk lock (logbuf_lock) is held by other thread during crash, there is a chance of deadlocking the crash on next printk, and blocking a possibly desired kdump. At the start of default_machine_crash_shutdown, make printk enter NMI context, as it will use per-cpu buffers to store