linux-kernel - Re: [PATCH next v3 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]

Message-ID: <YMmi5xoTOb82TKtJ@google.com>
Date:   Wed, 16 Jun 2021 16:06:15 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Alexander Potapenko <glider@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH next v3 1/2] dump_stack: move cpu lock to printk.c

On (21/06/15 23:39), John Ogness wrote:
> On 2021-06-15, John Ogness <john.ogness@...utronix.de> wrote:
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 114e9963f903..5369d8f33299 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -3532,3 +3532,70 @@ void kmsg_dump_rewind(struct kmsg_dump_iter *iter)
> >  EXPORT_SYMBOL_GPL(kmsg_dump_rewind);
> >  
> >  #endif
> > +
> > +#ifdef CONFIG_SMP
> > +static atomic_t printk_cpulock_owner = ATOMIC_INIT(-1);
> > +static bool printk_cpulock_nested;
> 
> I just realized that @printk_cpulock_nested will need to be an atomic_t
> counter to allow multiple nested levels since nesting can also occur

Strictly speaking, this is not nested printk, right? printk recursion is
handled in printk separately. This one is more like "nested dump_stack()-s",
or nested "error reporinting".

Shall this be a separate patch? Because the original code has never
limited nested error reporting contexts.