linux-kernel - Re: [PATCH 1/2] printk/panic: Access the main printk log in panic() only when safe

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: <20190718101123.GB10041@jagdpanzerIV>
Date:   Thu, 18 Jul 2019 19:11:53 +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 1/2] printk/panic: Access the main printk log in panic()
 only when safe

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

A side note:

I'd say that we also need to clear console_owner and re-init
console_owner_lock spin_lock, panic CPU can spin forever
otherwise; and I think it would also be reasonable to re-init
console_sem's spin_lock, yet another lock on which panic CPU
can spin forever. (Assuming that one of remote CPUs that we
have NMI killed had owned any of those locks).

Console drivers' locks are mostly OK, as long as drivers check
oops_in_progress in ->write() path and act accordingly, but
printk() has to deal with more than one lock (logbuf_lock)
before it invokes console drivers.

	-ss