From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E . McKenney" <paulmck@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Yong He <zhuangel570@gmail.com>,
Neeraj upadhyay <neeraj.iitr10@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Boqun Feng <boqun.feng@gmail.com>,
Uladzislau Rezki <urezki@gmail.com>, RCU <rcu@vger.kernel.org>
Subject: [PATCH 2/5] srcu: Only accelerate on enqueue time
Date: Wed, 4 Oct 2023 01:29:00 +0200 [thread overview]
Message-ID: <20231003232903.7109-3-frederic@kernel.org> (raw)
In-Reply-To: <20231003232903.7109-1-frederic@kernel.org>
Acceleration in SRCU happens on enqueue time for each new callback. This
operation is expected not to fail and therefore any similar attempt
from other places shouldn't find any remaining callbacks to accelerate.
Moreover accelerations performed beyond enqueue time are error prone
because rcu_seq_snap() then may return the snapshot for a new grace
period that is not going to be started.
Remove these dangerous and needless accelerations and introduce instead
assertions reporting leaking unaccelerated callbacks beyond enqueue
time.
Co-developed-by: Yong He <zhuangel570@gmail.com>
Co-developed-by: Joel Fernandes <joel@joelfernandes.org>
Co-developed-by: Neeraj upadhyay <neeraj.iitr10@gmail.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
kernel/rcu/srcutree.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 9fab9ac36996..560e99ec5333 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -784,8 +784,7 @@ static void srcu_gp_start(struct srcu_struct *ssp)
spin_lock_rcu_node(sdp); /* Interrupts already disabled. */
rcu_segcblist_advance(&sdp->srcu_cblist,
rcu_seq_current(&ssp->srcu_sup->srcu_gp_seq));
- (void)rcu_segcblist_accelerate(&sdp->srcu_cblist,
- rcu_seq_snap(&ssp->srcu_sup->srcu_gp_seq));
+ WARN_ON_ONCE(!rcu_segcblist_segempty(&sdp->srcu_cblist, RCU_NEXT_TAIL));
spin_unlock_rcu_node(sdp); /* Interrupts remain disabled. */
WRITE_ONCE(ssp->srcu_sup->srcu_gp_start, jiffies);
WRITE_ONCE(ssp->srcu_sup->srcu_n_exp_nodelay, 0);
@@ -1721,6 +1720,7 @@ static void srcu_invoke_callbacks(struct work_struct *work)
ssp = sdp->ssp;
rcu_cblist_init(&ready_cbs);
spin_lock_irq_rcu_node(sdp);
+ WARN_ON_ONCE(!rcu_segcblist_segempty(&sdp->srcu_cblist, RCU_NEXT_TAIL));
rcu_segcblist_advance(&sdp->srcu_cblist,
rcu_seq_current(&ssp->srcu_sup->srcu_gp_seq));
if (sdp->srcu_cblist_invoking ||
@@ -1750,8 +1750,6 @@ static void srcu_invoke_callbacks(struct work_struct *work)
*/
spin_lock_irq_rcu_node(sdp);
rcu_segcblist_add_len(&sdp->srcu_cblist, -len);
- (void)rcu_segcblist_accelerate(&sdp->srcu_cblist,
- rcu_seq_snap(&ssp->srcu_sup->srcu_gp_seq));
sdp->srcu_cblist_invoking = false;
more = rcu_segcblist_ready_cbs(&sdp->srcu_cblist);
spin_unlock_irq_rcu_node(sdp);
--
2.41.0
next prev parent reply other threads:[~2023-10-03 23:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-03 23:28 [PATCH 0/5] srcu fixes Frederic Weisbecker
2023-10-03 23:28 ` [PATCH 1/5] srcu: Fix callbacks acceleration mishandling Frederic Weisbecker
2023-10-03 23:29 ` Frederic Weisbecker [this message]
2023-10-10 6:46 ` [PATCH 2/5] srcu: Only accelerate on enqueue time Like Xu
2023-10-03 23:29 ` [PATCH 3/5] srcu: Remove superfluous callbacks advancing from srcu_start_gp() Frederic Weisbecker
2023-10-03 23:29 ` [PATCH 4/5] srcu: No need to advance/accelerate if no callback enqueued Frederic Weisbecker
2023-10-03 23:29 ` [PATCH 5/5] srcu: Explain why callbacks invocations can't run concurrently Frederic Weisbecker
2023-10-04 0:35 ` [PATCH 0/5] srcu fixes Paul E. McKenney
2023-10-04 3:21 ` Paul E. McKenney
2023-10-04 3:30 ` Paul E. McKenney
2023-10-04 9:36 ` Frederic Weisbecker
2023-10-04 14:06 ` Paul E. McKenney
2023-10-04 16:47 ` Paul E. McKenney
2023-10-04 21:27 ` Frederic Weisbecker
2023-10-04 21:54 ` Paul E. McKenney
2023-10-05 16:54 ` Paul E. McKenney
2023-10-10 11:23 ` Frederic Weisbecker
2023-10-04 9:35 ` Frederic Weisbecker
2023-10-04 9:25 ` Frederic Weisbecker
2023-10-07 10:24 ` zhuangel570
2023-10-10 11:27 ` Frederic Weisbecker
2023-10-10 13:20 ` zhuangel570
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=20231003232903.7109-3-frederic@kernel.org \
--to=frederic@kernel.org \
--cc=boqun.feng@gmail.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.iitr10@gmail.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=urezki@gmail.com \
--cc=zhuangel570@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