On Tue, Jul 16, 2019 at 10:28 AM Petr Mladek <pmla...@suse.com> wrote: > > 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.
Looks good. Reviewed-by: Konstantin Khebnikov <khlebni...@yandex-team.ru> > > > 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 >
