From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: bugzilla-daemon@bugzilla.kernel.org
Cc: sergey.senozhatsky@gmail.com,
Steven Rostedt <rostedt@goodmis.org>,
Petr Mladek <pmladek@suse.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Bug 199003] console stalled, cause Hard LOCKUP.
Date: Wed, 21 Mar 2018 16:28:51 +0900 [thread overview]
Message-ID: <20180321072851.GB468@jagdpanzerIV> (raw)
In-Reply-To: <bug-199003-14532-4aWzZJgGHz@https.bugzilla.kernel.org/>
On (03/20/18 09:34), bugzilla-daemon@bugzilla.kernel.org wrote:
[..]
> Thanks very much.
> commit e480af09c49736848f749a43dff2c902104f6691 avoided the NMI watchdog
> trigger.
Hm, okay... But "touch_nmi_watchdog() everywhere printk/console-related"
is not exactly where I wanted us to be.
By the way e480af09c49736848f749a43dff2c902104f6691 is from 2006.
Are you sure you meant exactly that commit? What kernel do you use?
Are you saying that none of Steven's patches helped on your setups?
> And this patch may avdoid long time blocking:
> https://lkml.org/lkml/2018/3/8/584
>
> We've test it several days.
Hm, printk_deferred is a bit dangerous; it moves console_unlock() to
IRQ. So you still can have the problem of stuck CPUs, it's just now
you shut up the watchdog. Did you test Steven's patches?
A tricky part about printk_deferred() is that it does not use hand off
mechanism. And even more... What we have with "printk vs printk"
sceanrio
CPU0 CPU1 ... CPUN
printk printk
console_unlock hand off printk
console_unlock hand off
console_unlock
turns into a good old "one CPU prints it all" when we have "printk vs
printk_deferred" case. Because printk_deferred just log_store messages
and then _may be_ it grabs the console_sem from IRQ and invokes
console_unlock().
So it's something like this
CPU0 CPU1 ... CPUN
printk printk_deffered
console_unlock printk_deferred
console_unlock
console_unlock
... ... ...
printk_deffered printk_deferred
console_unlock
console_unlock
// offtopic "I can has printk_kthread?"
You now touch_nmi_watchdog() from the console driver [well... at least this
is what e480af09c4973 is doing, but I'm not sure I see how come you didn't
have it applied], so that's why you don't see hard lockups on that CPU0. But
your printing CPU still can stuck, which will defer RCUs on that CPU, etc.
etc. etc. So I'd say that those two approaches
printk_deferred + touch_nmi_watchdog
combined can do quite some harm. One thing for sure - they don't really fix
any problems.
-ss
next prev parent reply other threads:[~2018-03-21 7:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-199003-14532@https.bugzilla.kernel.org/>
[not found] ` <bug-199003-14532-lzL5ySZS5x@https.bugzilla.kernel.org/>
2018-03-05 9:27 ` [Bug 199003] console stalled, cause Hard LOCKUP Sergey Senozhatsky
[not found] ` <bug-199003-14532-4aWzZJgGHz@https.bugzilla.kernel.org/>
2018-03-21 7:28 ` Sergey Senozhatsky [this message]
[not found] ` <bug-199003-14532-DgJdGAHEOE@https.bugzilla.kernel.org/>
2018-03-26 5:18 ` Sergey Senozhatsky
[not found] ` <bug-199003-14532-IBTfRpvy7t@https.bugzilla.kernel.org/>
2018-03-27 10:37 ` Sergey Senozhatsky
[not found] <bug-199003-8243@https.bugzilla.kernel.org/>
[not found] ` <bug-199003-8243-Txkdkdv5Cm@https.bugzilla.kernel.org/>
2018-03-21 13:44 ` Steven Rostedt
2018-03-22 2:14 ` Sergey Senozhatsky
2018-03-22 2:34 ` Sergey Senozhatsky
2018-03-22 22:25 ` Steven Rostedt
2018-03-23 12:06 ` Sergey Senozhatsky
2018-03-23 13:16 ` Petr Mladek
2018-03-26 5:12 ` Sergey Senozhatsky
2018-03-26 9:26 ` 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=20180321072851.GB468@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.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.