[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200924084541.GA541@jagdpanzerIV.localdomain>
Date: Thu, 24 Sep 2020 17:45:41 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: John Ogness <john.ogness@...utronix.de>
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 (20/09/22 17:44), John Ogness 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?
-ss
Powered by blists - more mailing lists