linux-kernel - Re: [PATCH printk 4/5] printk: remove logbuf_lock, add syslog

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87d02b7cnk.fsf@jogness.linutronix.de>
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