Messages in this thread | | | From | Petr Mladek <> | Subject | [PATCH 0/2] panic/printk/x86: Prevent some more printk-related deadlocks in panic() | Date | Tue, 16 Jul 2019 09:28:03 +0200 |
| |
Hi,
I have found some spare duct tape and wrapped some more printk-related deadlocks in panic().
More seriously, someone reported a deadlock in panic(). Some non-trivial debugging pointed out a problem with the following combination:
+ x86_64 architecture + panic() + pstore configured as message dumper (kmsg_dump()) + crash kernel configured + crash_kexec_post_notifiers
In this case, CPUs are stopped by crash_smp_send_stop(). It uses NMI but it does not modify cpu_online_mask. Therefore logbuf_lock might stay locked, see 2nd patch for more details.
The above is a real corner case. But similar problem seems to be even in the common situations on architectures that do not use NMI in smp_send_stop() as a fallback, see 1st patch.
Back to the duct tape. I hope that we will get rid of these problems with the lockless printk ringbuffer rather sooner than later. But it still might take some time. And the two fixes might be useful also for stable kernels.
Petr Mladek (2): printk/panic: Access the main printk log in panic() only when safe printk/panic/x86: Allow to access printk log buffer after crash_smp_send_stop()
arch/x86/kernel/crash.c | 6 +++++- include/linux/printk.h | 6 ++++++ kernel/panic.c | 49 +++++++++++++++++++++++++++------------------ kernel/printk/printk_safe.c | 37 ++++++++++++++++++++++------------ 4 files changed, 65 insertions(+), 33 deletions(-)
-- 2.16.4
| |