All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Rik van Riel <riel@fb.com>, Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, kernel-team@fb.com,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH] lockdep: Avoid triggering hardlockup from debug_show_all_locks()
Date: Tue, 23 Jan 2018 13:11:54 -0800	[thread overview]
Message-ID: <20180123211154.GI1771050@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20180123160054.325ff326@gandalf.local.home>

Hello, Steven.

On Tue, Jan 23, 2018 at 04:00:54PM -0500, Steven Rostedt wrote:
> On Tue, 23 Jan 2018 12:57:06 -0800
> Tejun Heo <tj@kernel.org> wrote:
> 
> > Yeah, it's ridiculous how often printk ends up escalating otherwise
> > recoverable situations into system crashes.  I don't know what the
> > right answer is.  For spurious NMI hardlockups, maybe auditing debug
> > paths and adding touch_nmi_watchdog() would be enough but that also is
> > a pretty leaky approach.
> 
> What about if every printk were to touch NMI watchdog?
> 
> NMI watchdog is really there for when the system locks up. If the
> system is locked up doing printk, at least we see what is happening,
> and not a total freeze.

Yeah, that would definitely be a solution.  The downside is that when
the system completely locks up from printk storm while holding
critical locks (say, tasklist_lock), the watchdog won't be able to
reset the system.  I guess the judgement would depend on what one
expects of the NMI watchdog, but I personally would be happier with
printk touching NMI automatically.

Thanks.

-- 
tejun

  reply	other threads:[~2018-01-23 21:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-22 22:00 [PATCH] lockdep: Avoid triggering hardlockup from debug_show_all_locks() Tejun Heo
2018-01-23 19:03 ` Rik van Riel
2018-01-23 20:57   ` Tejun Heo
2018-01-23 21:00     ` Steven Rostedt
2018-01-23 21:11       ` Tejun Heo [this message]
2018-01-24  2:49         ` Sergey Senozhatsky
2018-01-24  2:54           ` Steven Rostedt
2018-01-24  5:00             ` Sergey Senozhatsky
2018-01-24 19:10               ` Tejun Heo
2018-01-24 10:38 ` [tip:locking/urgent] locking/lockdep: " tip-bot for Tejun Heo

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=20180123211154.GI1771050@devbig577.frc2.facebook.com \
    --to=tj@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=riel@fb.com \
    --cc=rostedt@goodmis.org \
    --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.