From: Petr Mladek <pmladek@suse.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: NMI watchdog dump does not print on hard lockup
Date: Mon, 16 Oct 2017 13:12:39 +0200 [thread overview]
Message-ID: <20171016111239.GK2795@pathway.suse.cz> (raw)
In-Reply-To: <CA+55aFxCnmd8+9qYs1pBG+N3ULQjMOV5S6yZCjA-w_pwc6kXyA@mail.gmail.com>
On Fri 2017-10-13 12:12:29, Linus Torvalds wrote:
> On Fri, Oct 13, 2017 at 6:18 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Or add the following case: The watchdog triggers, does the print, then
> > if it triggers again in a certain amount of time, and the print still
> > hasn't been flushed, the flush happens then.
Sounds good to me.
> By the time 40 sec has passed, I suspect most people have just
> rebooted the machine.
This might be the case for a desktop. But people might be more
conservative in case of big servers or when debugging. These might
be desperate to keep going or see something.
> I think an NMI watchdog should just force the flush - the same way an
> oops should. Deadlocks aren't really relevant if something doesn't get
> printed out anyway.
We expicititely flush the NMI buffers in panic() when there is
not other way to see them. But it is questional in other situations.
Sometimes the flush might be the only way to see the messages
and sometimes printk() might unnecessarily cause a deadlock.
IMHO, the only solution is to make it optional.
Best Regards,
Petr
next prev parent reply other threads:[~2017-10-16 11:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 16:16 NMI watchdog dump does not print on hard lockup Steven Rostedt
2017-10-12 19:26 ` Peter Zijlstra
2017-10-13 11:14 ` Petr Mladek
2017-10-13 13:18 ` Steven Rostedt
2017-10-13 19:12 ` Linus Torvalds
2017-10-16 11:12 ` Petr Mladek [this message]
2017-10-16 13:13 ` Sergey Senozhatsky
2017-10-16 14:15 ` Steven Rostedt
2017-10-17 7:50 ` Sergey Senozhatsky
2018-10-23 6:49 ` Sergey Senozhatsky
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=20171016111239.GK2795@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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.