[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 24 Sep 2020 11:27:51 +0206
From: John Ogness <john.ogness@...utronix.de>
To: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc: Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk 4/5] printk: remove logbuf_lock, add syslog_lock
On 2020-09-24, Sergey Senozhatsky <sergey.senozhatsky@...il.com> wrote:
> [..]
>> void printk_safe_flush_on_panic(void)
>> {
>> - /*
>> - * Make sure that we could access the main ring buffer.
>> - * Do not risk a double release when more CPUs are up.
>> - */
>> - if (raw_spin_is_locked(&logbuf_lock)) {
>> - if (num_online_cpus() > 1)
>> - return;
>> -
>> - debug_locks_off();
>> - raw_spin_lock_init(&logbuf_lock);
>
> If we panic() with syslog_lock locked then we need to zap syslog_lock
> and disable debug_locks for kmsg_dump() to succeed. Otherwise panic()
> may deadlock:
>
> syslog_lock_irq()
> -> NMI
> panic()
> ...
> printk_safe_flush_on_panic();
> kmsg_dump(KMSG_DUMP_PANIC); // syslog_lock_irqsave(flags)
> ...
>
> Did I miss the point where we make sure that kmsg_dump() will not
> deadlock?
You are correct. Thanks.
@clear_seq should either become atomic64 or kmsg_dump() should start
from the oldest available message (seq=0).
John Ogness
Powered by blists - more mailing lists