All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hoeun Ryu" <hoeun.ryu@lge.com>
To: "'Sergey Senozhatsky'" <sergey.senozhatsky.work@gmail.com>,
	"'Hoeun Ryu'" <hoeun.ryu@lge.com.com>
Cc: "'Petr Mladek'" <pmladek@suse.com>,
	"'Sergey Senozhatsky'" <sergey.senozhatsky@gmail.com>,
	"'Steven Rostedt'" <rostedt@goodmis.org>,
	<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH]  printk: make printk_safe_flush safe in NMI context by skipping flushing
Date: Wed, 30 May 2018 07:43:32 +0900	[thread overview]
Message-ID: <03d301d3f79e$78ec4580$6ac4d080$@lge.com> (raw)
In-Reply-To: <20180529121315.GE438@jagdpanzerIV>


> -----Original Message-----
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.work@gmail.com]
> Sent: Tuesday, May 29, 2018 9:13 PM
> To: Hoeun Ryu <hoeun.ryu@lge.com.com>
> Cc: Petr Mladek <pmladek@suse.com>; Sergey Senozhatsky
> <sergey.senozhatsky@gmail.com>; Steven Rostedt <rostedt@goodmis.org>;
> Hoeun Ryu <hoeun.ryu@lge.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] printk: make printk_safe_flush safe in NMI context by
> skipping flushing
> 
> On (05/29/18 11:51), Hoeun Ryu wrote:
> >  Make printk_safe_flush() safe in NMI context.
> > nmi_trigger_cpumask_backtrace() can be called in NMI context. For
> example the
> > function is called in watchdog_overflow_callback() if the flag of
> hardlockup
> > backtrace (sysctl_hardlockup_all_cpu_backtrace) is true and
> > watchdog_overflow_callback() function is called in NMI context on some
> > architectures.
> >  Calling printk_safe_flush() in nmi_trigger_cpumask_backtrace()
> eventually tries
> > to lock logbuf_lock in vprintk_emit() but the logbuf_lock can be already
> locked in
> > preempted contexts (task or irq in this case) or by other CPUs and it
> may cause
> > deadlocks.
> >  By making printk_safe_flush() safe in NMI context, the backtrace
> triggering CPU
> > just skips flushing if the lock is not avaiable in NMI context. The
> messages in
> > per-cpu nmi buffer of the backtrace triggering CPU can be lost if the
> CPU is in
> > hard lockup (because irq is disabled here) but if panic() is not called.
> The
> > flushing can be delayed by the next irq work in normal cases.
> 
> Any chance we can add more info to the commit message? E.g. backtraces
> which would describe "how" is this possible (like the one I posted in
> another email). Just to make it more clear.
> 

OK, I will.

> > @@ -254,6 +254,16 @@ void printk_safe_flush(void)
> >  {
> >  	int cpu;
> >
> > +	/*
> > +	 * Just avoid deadlocks here, we could loose the messages in per-
> cpu nmi buffer
> > +	 * in the case that hardlockup happens but panic() is not called
> (irq_work won't
> > +	 * work).
> > +	 * The flushing can be delayed by the next irq_work if flushing is
> skippped here
>
^^ skipped
> 

Typo will be fixed.

> 	-ss

  reply	other threads:[~2018-05-29 22:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29  2:51 [PATCH] printk: make printk_safe_flush safe in NMI context by skipping flushing Hoeun Ryu
2018-05-29 12:13 ` Sergey Senozhatsky
2018-05-29 22:43   ` Hoeun Ryu [this message]
2018-05-30  8:32   ` Petr Mladek
2018-06-01  1:55     ` Hoeun Ryu
2018-06-01  5:17     ` Hoeun Ryu
2018-06-01  9:05       ` 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='03d301d3f79e$78ec4580$6ac4d080$@lge.com' \
    --to=hoeun.ryu@lge.com \
    --cc=hoeun.ryu@lge.com.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.