linux-kernel - Re: [PATCH 2/2] printk/panic/x86: Allow to access printk log buffer after crash_smp_send

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]

Date:   Thu, 18 Jul 2019 19:47:56 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        John Ogness <john.ogness@...utronix.de>,
        Petr Tesarik <ptesarik@...e.cz>,
        Konstantin Khlebnikov <koct9i@...il.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] printk/panic/x86: Allow to access printk log buffer
 after crash_smp_send_stop()

On (07/16/19 09:28), Petr Mladek wrote:
[..]
> +int printk_bust_lock_safe(bool kdump_smp_stop)
>  {
>  	if (!raw_spin_is_locked(&logbuf_lock))
>  		return 0;
>  
> -	if (num_online_cpus() == 1) {
> +	if (num_online_cpus() == 1 || kdump_smp_stop)  {
>  		debug_locks_off();
>  		raw_spin_lock_init(&logbuf_lock);
>  		return 0;

Let me test the waters. Criticize the following idea:

Can we, sort of, disconnect "supposed to be dead" CPUs from printk()
so then we can unconditionally re-init printk() from panic-CPU?

We have per-CPU printk_state; so panic-CPU can set, let's say,
DEAD_CPUS_TELL_NO_TALES bit on all CPUs but self, and vprintk_func()
will do nothing if DEAD_CPUS_TELL_NO_TALES bit set on particular
CPU. Foreign CPUs are not even supposed to be alive, and smp_send_stop()
waits for IPI acks from secondary CPUs long enough on average (need
to check that) so if one of the CPUs is misbehaving and doesn't want
to die (geez...) we will just "disconnect" it from printk() to minimize
possible logbuf/console drivers interventions and then proceed with
panic; assuming that misbehaving CPUs are actually up to something
sane. Sometimes, you know, in some cases, those CPUs are already dead:
either accidentally powered off, or went completely nuts and do nothing,
etc. etc. but we still can kdump() and console_flush_on_panic().

	-ss