linux-kernel - Re: [PATCH next v3 01/15] um: synchronize kmsg

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: <YD0c5jMDTTKVrU8X@alley>
Date:   Mon, 1 Mar 2021 17:57:10 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
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, Jeff Dike <jdike@...toit.com>,
        Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Thomas Meyer <thomas@...3r.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-um@...ts.infradead.org
Subject: Re: [PATCH next v3 01/15] um: synchronize kmsg_dumper

On Mon 2021-03-01 17:16:35, Petr Mladek wrote:
> On Thu 2021-02-25 21:24:24, John Ogness wrote:
> > The kmsg_dumper can be called from any context and CPU, possibly
> > from multiple CPUs simultaneously. Since a static buffer is used
> > to retrieve the kernel logs, this buffer must be protected against
> > simultaneous dumping. Skip dumping if another context is already
> > dumping.
> > 
> > Signed-off-by: John Ogness <john.ogness@...utronix.de>
> > Reviewed-by: Petr Mladek <pmladek@...e.com>
> > ---
> >  arch/um/kernel/kmsg_dump.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c
> > index 6516ef1f8274..4869e2cc787c 100644
> > --- a/arch/um/kernel/kmsg_dump.c
> > +++ b/arch/um/kernel/kmsg_dump.c
> > @@ -1,5 +1,6 @@
> >  // SPDX-License-Identifier: GPL-2.0
> >  #include <linux/kmsg_dump.h>
> > +#include <linux/spinlock.h>
> >  #include <linux/console.h>
> >  #include <linux/string.h>
> >  #include <shared/init.h>
> > @@ -9,6 +10,7 @@
> >  static void kmsg_dumper_stdout(struct kmsg_dumper *dumper,
> >  				enum kmsg_dump_reason reason)
> >  {
> > +	static DEFINE_SPINLOCK(lock);
> >  	static char line[1024];
> >  	struct console *con;
> >  	size_t len = 0;
> > @@ -29,11 +31,16 @@ static void kmsg_dumper_stdout(struct kmsg_dumper *dumper,
> >  	if (con)
> >  		return;
> >  
> > +	if (!spin_trylock(&lock))
> 
> I have almost missed this. It is wrong. The last version correctly
> used
> 
> 	if (!spin_trylock_irqsave(&lock, flags))
> 
> kmsg_dump(KMSG_DUMP_PANIC) is called in panic() with interrupts
> disabled. We have to store the flags here.

Ah, I get always confused with these things. spin_trylock() can
actually get called in a context with IRQ disabled. So it is not
as wrong as I thought.

But still. panic() and kmsg_dump() can be called in IRQ context.
So, this function might be called in IRQ context. So, it feels
more correct to use the _irqsafe variant here.

I know that there is the trylock so it probably does not matter much.
Well, the disabled irq might help to serialize the two calls when
one is in normal context and the other would happen in IRQ one.

As I said, using _irqsafe variant looks better to me.

What do you think, please?

Best Regards,
Petr

PS: Heh, IMHO, I do not use an authoritative style too often. But my
feeling is that every time I use it then I am proven to be wrong.
And it has happened again.