From: Tejun Heo <tj@kernel.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: Can RCU stall lead to hard lockups?
Date: Tue, 9 Jan 2018 06:11:14 -0800 [thread overview]
Message-ID: <20180109141114.GF3668920@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20180109042425.GS9671@linux.vnet.ibm.com>
Hello, Paul.
On Mon, Jan 08, 2018 at 08:24:25PM -0800, Paul E. McKenney wrote:
> > I don't know the RCU code at all but it *looks* like the first CPU is
> > taking a sweet while flushing printk buffer while holding a lock (the
> > console is IPMI serial console, which faithfully emulates 115200 baud
> > rate), and everyone else seems stuck waiting for that spinlock in
> > rcu_check_callbacks().
> >
> > Does this sound possible?
>
> 115200 baud? Ouch!!! That -will- result in trouble from console
> printing, and often also in RCU CPU stall warnings.
It could even be slower than 115200, and we occassionally see RCU
stall warnings caused by printk storms, for example, while the kernel
is trying to dump a lot of info after an OOM. That's an issue we
probably want to improve from printk side; however, they don't usually
lead to NMI hard lockup detector kicking in and crashing the machine,
which is the peculiarity here.
Hmmm... show_state_filter(), the function which dumps all task
backtraces, share a similar problem and it avoids it by explicitly
calling touch_nmi_watchdog(). Maybe we can do something like the
following from RCU too?
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index db85ca3..3c4c4d3 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -561,8 +561,14 @@ static void rcu_print_detail_task_stall_rnp(struct rcu_node *rnp)
}
t = list_entry(rnp->gp_tasks->prev,
struct task_struct, rcu_node_entry);
- list_for_each_entry_continue(t, &rnp->blkd_tasks, rcu_node_entry)
+ list_for_each_entry_continue(t, &rnp->blkd_tasks, rcu_node_entry) {
+ touch_nmi_watchdog();
+ /*
+ * We could be printing a lot of these messages while
+ * holding a spinlock. Avoid triggering hard lockup.
+ */
sched_show_task(t);
+ }
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
}
@@ -1678,6 +1684,12 @@ static void print_cpu_stall_info(struct rcu_state *rsp, int cpu)
char *ticks_title;
unsigned long ticks_value;
+ /*
+ * We could be printing a lot of these messages while holding a
+ * spinlock. Avoid triggering hard lockup.
+ */
+ touch_nmi_watchdog();
+
if (rsp->gpnum == rdp->gpnum) {
ticks_title = "ticks this GP";
ticks_value = rdp->ticks_this_gp;
next prev parent reply other threads:[~2018-01-09 14:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 3:52 Tejun Heo
2018-01-09 4:24 ` Paul E. McKenney
2018-01-09 14:11 ` Tejun Heo [this message]
2018-01-09 15:22 ` Paul E. McKenney
2018-01-09 18:47 ` [PATCH] RCU: Call touch_nmi_watchdog() while printing stall warnings Tejun Heo
2018-01-09 18:52 ` [PATCH trivial-v2] " Tejun Heo
2018-01-09 20:05 ` Paul E. McKenney
2018-01-10 5:34 ` Sergey Senozhatsky
2018-01-10 14:57 ` Tejun Heo
2018-01-11 0:45 ` Sergey Senozhatsky
2018-02-02 23:44 ` Can RCU stall lead to hard lockups? Serge E. Hallyn
2018-02-03 20:50 ` Paul E. McKenney
2018-02-07 2:33 ` Serge E. Hallyn
2018-02-07 2:53 ` Paul E. McKenney
2018-02-07 2:55 ` Serge E. Hallyn
2018-02-07 3:16 ` Paul E. McKenney
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=20180109141114.GF3668920@devbig577.frc2.facebook.com \
--to=tj@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome