public inbox for linux-um@lists.infradead.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Jeff Dike <jdike@addtoit.com>,
	linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Thomas Meyer <thomas@m3y3r.de>,
	Anton Ivanov <anton.ivanov@cambridgegreys.com>
Subject: Re: [PATCH next v3 01/15] um: synchronize kmsg_dumper
Date: Mon, 1 Mar 2021 17:57:10 +0100	[thread overview]
Message-ID: <YD0c5jMDTTKVrU8X@alley> (raw)
In-Reply-To: <YD0TYkWZqcS/VO8Z@alley>

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@linutronix.de>
> > Reviewed-by: Petr Mladek <pmladek@suse.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.

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


  reply	other threads:[~2021-03-01 16:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 20:24 [PATCH next v3 00/15] printk: remove logbuf_lock John Ogness
2021-02-25 20:24 ` [PATCH next v3 01/15] um: synchronize kmsg_dumper John Ogness
2021-03-01 16:16   ` Petr Mladek
2021-03-01 16:57     ` Petr Mladek [this message]
2021-03-02  8:06       ` John Ogness
2021-03-02 10:12         ` Petr Mladek
2021-02-25 20:24 ` [PATCH next v3 12/15] printk: introduce a kmsg_dump iterator John Ogness
2021-02-25 21:59   ` Kees Cook
2021-02-26  7:59   ` John Ogness
2021-03-01 18:07   ` Petr Mladek
2021-03-02 13:20     ` John Ogness
2021-03-02 13:55       ` Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YD0c5jMDTTKVrU8X@alley \
    --to=pmladek@suse.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=jdike@addtoit.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=thomas@m3y3r.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox