linux-kernel - Re: [PATCH next v1 1/2] dump_stack: move cpu lock to printk.c

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:   Tue, 01 Jun 2021 16:21:52 +0200
From:   John Ogness <john.ogness@...utronix.de>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Valentin Schneider <valentin.schneider@....com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Alexander Potapenko <glider@...gle.com>,
        "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH next v1 1/2] dump_stack: move cpu lock to printk.c

On 2021-06-01, Petr Mladek <pmladek@...e.com> wrote:
>> +void printk_cpu_lock(unsigned int *cpu_store, unsigned long *flags)
>
> I think about calling this printk_cpu_lock_irqsave() to make it clear
> that it disables interrupts.

Agreed.

> Strictly speaking, it should be enough to disable preemption. If it is
> safe when interrupted by NMI, it must be safe also when interrupted
> by a normal interrupt.
>
> I guess that the interrupts are disabled because it reduces the risk
> of nested (messed) backtraces.

If it was just about synchronizing output triggered by sysreq, then it
probably would be acceptable to leave interrupts active. But when atomic
consoles are involved, we are talking about a crashing machine that is
trying to get log messages out. Any interrupt is a risk that the machine
may not survive long enough to return from that interruption.

John Ogness