summaryrefslogtreecommitdiff
path: root/arch/powerpc/crypto
diff options
context:
space:
mode:
authorNicholas Piggin <npiggin@gmail.com>2021-11-19 14:31:46 +0300
committerMichael Ellerman <mpe@ellerman.id.au>2021-11-29 15:08:43 +0300
commite012c499985c608c936410d8bab29d9596d62859 (patch)
treec21fd1d9a026ed1b096a1fec92bc71ed848d10d4 /arch/powerpc/crypto
parent57dd3a7bdf311e4a499fe0decabcdf2484e2538a (diff)
downloadlinux-e012c499985c608c936410d8bab29d9596d62859.tar.xz
powerpc/watchdog: help remote CPUs to flush NMI printk output
The printk layer at the moment does not seem to have a good way to force flush printk messages that are created in NMI context, except in the panic path. NMI-context printk messages normally get to the console with irq_work, but that won't help if the CPU is stuck with irqs disabled, as can be the case for hard lockup watchdog messages. The watchdog currently flushes the printk buffers after detecting a lockup on remote CPUs, but they may not have processed their NMI IPI yet by that stage, or they may have self-detected a lockup in which case they won't go via this NMI IPI path. Improve the situation by having NMI-context mark a flag if it called printk, and have watchdog timer interrupts check if that flag was set and try to flush if it was. Latency is not a big problem because we were already stuck for a while, just need to try to make sure the messages eventually make it out. Depends-on: 5d5e4522a7f4 ("printk: restore flushing of NMI buffers on remote CPUs after NMI backtraces") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Laurent Dufour <ldufour@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211119113146.752759-6-npiggin@gmail.com
Diffstat (limited to 'arch/powerpc/crypto')
0 files changed, 0 insertions, 0 deletions