linux-kernel - Re: [PATCH v2 4/4] printk: Drop console

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:   Fri, 28 Jan 2022 14:55:49 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     John Ogness <john.ogness@...utronix.de>,
        Petr Mladek <pmladek@...e.com>
Cc:     Stephen Brennan <stephen.s.brennan@...cle.com>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Arnd Bergmann <arnd@...db.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Sebastian Reichel <sre@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/4] printk: Drop console_sem during panic

On (22/01/27 16:03), Petr Mladek wrote:
> On Thu 2022-01-27 10:28:53, John Ogness wrote:
> > On 2022-01-26, Stephen Brennan <stephen.s.brennan@...cle.com> wrote:
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -2759,7 +2782,7 @@ void console_unlock(void)
> > >  	 * flush, no worries.
> > >  	 */
> > >  	retry = prb_read_valid(prb, next_seq, NULL);
> > > -	if (retry && console_trylock())
> > > +	if (retry && !abandon_console_lock_in_panic() && console_trylock())
> > 
> > As Sergey suggested [0], I would like to see the call to
> > abandon_console_lock_in_panic() move inside console_trylock(). This will
> > help to avoid the race between NMI CPU halt and the internal sema.lock
> > spinlock.

Thanks John.

> I would prefer if it is done as a followup patch. The code in this
> patch is still needed. It helps when the non-panic CPU is busy
> with pushing many pending messages. Also it is a more conservative
> approach.

No objections. This series fixes issue at hand, so conservative approach
makes sense.

On the other hand, we are at -rc1 and it seems like a very good time to
discuss/look into/work on/etc. solution for the remaining cases/races/etc.