From: Zqiang <qiang.zhang1211@gmail.com>
To: paulmck@kernel.org, frederic@kernel.org,
neeraj.upadhyay@kernel.org, joel@joelfernandes.org,
urezki@gmail.com, boqun.feng@gmail.com
Cc: qiang.zhang1211@gmail.com, rcu@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH] rcu/nocb: Fix the WARN_ON_ONCE() in rcu_nocb_rdp_deoffload()
Date: Sun, 20 Oct 2024 20:51:19 +0800 [thread overview]
Message-ID: <20241020125119.14751-1-qiang.zhang1211@gmail.com> (raw)
Currently, running rcutorture test with torture_type=rcu fwd_progress=8
n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60
test_boost=2, will trigger the following warning:
WARNING: CPU: 19 PID: 100 at kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0
RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0
[18839.537322] Call Trace:
[18839.538006] <TASK>
[18839.538596] ? __warn+0x7e/0x120
[18839.539491] ? rcu_nocb_rdp_deoffload+0x292/0x2a0
[18839.540757] ? report_bug+0x18e/0x1a0
[18839.541805] ? handle_bug+0x3d/0x70
[18839.542837] ? exc_invalid_op+0x18/0x70
[18839.543959] ? asm_exc_invalid_op+0x1a/0x20
[18839.545165] ? rcu_nocb_rdp_deoffload+0x292/0x2a0
[18839.546547] rcu_nocb_cpu_deoffload+0x70/0xa0
[18839.547814] rcu_nocb_toggle+0x136/0x1c0
[18839.548960] ? __pfx_rcu_nocb_toggle+0x10/0x10
[18839.550073] kthread+0xd1/0x100
[18839.550958] ? __pfx_kthread+0x10/0x10
[18839.552008] ret_from_fork+0x2f/0x50
[18839.553002] ? __pfx_kthread+0x10/0x10
[18839.553968] ret_from_fork_asm+0x1a/0x30
[18839.555038] </TASK>
CPU0 CPU2 CPU3
//rcu_nocb_toggle //nocb_cb_wait //rcutorture
// deoffload CPU1 // process CPU1's rdp
rcu_barrier()
rcu_segcblist_entrain()
rcu_segcblist_add_len(1);
// len == 2
// enqueue barrier
// callback to CPU1's
// rdp->cblist
rcu_do_batch()
// invoke CPU1's rdp->cblist
// callback
rcu_barrier_callback()
rcu_barrier()
mutex_lock(&rcu_state.barrier_mutex);
// still see len == 2
// enqueue barrier callback
// to CPU1's rdp->cblist
rcu_segcblist_entrain()
rcu_segcblist_add_len(1);
// len == 3
// decrement len
rcu_segcblist_add_len(-2);
kthread_parkme()
// CPU1's rdp->cblist len == 1
// Warn because there is
// still a pending barrier
// trigger warning
WARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist));
cpus_read_unlock();
// wait CPU1 comes online
// invoke barrier callback on
// CPU1 rdp's->cblist
wait_for_completion(&rcu_state.barrier_completion);
// deoffload CPU4
cpus_read_lock()
rcu_barrier()
mutex_lock(&rcu_state.barrier_mutex);
// block on barrier_mutex
// wait rcu_barrier() on
// CPU3 to unlock barrier_mutex
// but CPU3 unlock barrier_mutex
// need to wait CPU1 comes online
// when CPU1 going online will block on cpus_write_lock
The above scenario will not only trigger WARN_ON_ONCE(), but also
trigger deadlock, this commit therefore check rdp->cblist length
before invoke kthread_parkme(), and the kthread_parkme() is not
invoke until length reaches zero.
Signed-off-by: Zqiang <qiang.zhang1211@gmail.com>
---
kernel/rcu/tree_nocb.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h
index 8648233e1717..a2b0ebdefee3 100644
--- a/kernel/rcu/tree_nocb.h
+++ b/kernel/rcu/tree_nocb.h
@@ -893,6 +893,12 @@ static inline bool nocb_cb_wait_cond(struct rcu_data *rdp)
return !READ_ONCE(rdp->nocb_cb_sleep) || kthread_should_park();
}
+static inline bool nocb_cblist_empty(struct rcu_data *rdp)
+{
+ return !(rcu_rdp_is_offloaded(rdp) &&
+ WARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist)));
+}
+
/*
* Invoke any ready callbacks from the corresponding no-CBs CPU,
* then, if there are no more, wait for more to appear.
@@ -907,7 +913,7 @@ static void nocb_cb_wait(struct rcu_data *rdp)
swait_event_interruptible_exclusive(rdp->nocb_cb_wq,
nocb_cb_wait_cond(rdp));
- if (kthread_should_park()) {
+ if (kthread_should_park() && nocb_cblist_empty(rdp)) {
kthread_parkme();
} else if (READ_ONCE(rdp->nocb_cb_sleep)) {
WARN_ON(signal_pending(current));
--
2.17.1
next reply other threads:[~2024-10-20 12:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-20 12:51 Zqiang [this message]
2024-10-20 23:14 ` Frederic Weisbecker
2024-10-21 0:39 ` Z qiang
2024-10-21 11:01 ` Z qiang
2024-10-21 11:44 ` Frederic Weisbecker
2024-10-21 12:33 ` Z qiang
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=20241020125119.14751-1-qiang.zhang1211@gmail.com \
--to=qiang.zhang1211@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=urezki@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®