All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Joel Fernandes <joelagnelf@nvidia.com>,
	Neeraj Upadhyay <neeraj.upadhyay@amd.com>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>, rcu <rcu@vger.kernel.org>
Subject: [PATCH 2/5] rcu/exp: Remove confusing needless full barrier on task unblock
Date: Fri, 14 Mar 2025 15:36:39 +0100	[thread overview]
Message-ID: <20250314143642.72554-3-frederic@kernel.org> (raw)
In-Reply-To: <20250314143642.72554-1-frederic@kernel.org>

A full memory barrier in the RCU-PREEMPT task unblock path advertizes
to order the context switch (or rather the accesses prior to
rcu_read_unlock()) with the expedited grace period fastpath.

However the grace period can not complete without the rnp calling into
rcu_report_exp_rnp() with the node locked. This reports the quiescent
state in a fully ordered fashion against updater's accesses thanks to:

1) The READ-SIDE smp_mb__after_unlock_lock() barrier accross nodes
   locking while propagating QS up to the root.

2) The UPDATE-SIDE smp_mb__after_unlock_lock() barrier while holding the
   the root rnp to wait/check for the GP completion.

3) The (perhaps redundant given step 1) and 2)) smp_mb() in rcu_seq_end()
   before the grace period completes.

This makes the explicit barrier in this place superflous. Therefore
remove it as it is confusing.

Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 kernel/rcu/tree_plugin.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 3c0bbbbb686f..d51cc7a5dfc7 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -534,7 +534,6 @@ rcu_preempt_deferred_qs_irqrestore(struct task_struct *t, unsigned long flags)
 		WARN_ON_ONCE(rnp->completedqs == rnp->gp_seq &&
 			     (!empty_norm || rnp->qsmask));
 		empty_exp = sync_rcu_exp_done(rnp);
-		smp_mb(); /* ensure expedited fastpath sees end of RCU c-s. */
 		np = rcu_next_node_entry(t, rnp);
 		list_del_init(&t->rcu_node_entry);
 		t->rcu_blocked_node = NULL;
-- 
2.48.1


  parent reply	other threads:[~2025-03-14 14:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14 14:36 [PATCH 0/5 v2] rcu/exp updates Frederic Weisbecker
2025-03-14 14:36 ` [PATCH 1/5] rcu/exp: Protect against early QS report Frederic Weisbecker
2025-03-15 23:59   ` Joel Fernandes
2025-03-16 11:07     ` Frederic Weisbecker
2025-03-16 14:23       ` Joel Fernandes
2025-03-16 22:24         ` Frederic Weisbecker
2025-03-18 17:17   ` Paul E. McKenney
2025-03-19  8:58     ` Frederic Weisbecker
2025-03-14 14:36 ` Frederic Weisbecker [this message]
2025-03-18 17:18   ` [PATCH 2/5] rcu/exp: Remove confusing needless full barrier on task unblock Paul E. McKenney
2025-03-19  9:01     ` Frederic Weisbecker
2025-03-19 14:03       ` Paul E. McKenney
2025-03-14 14:36 ` [PATCH 3/5] rcu/exp: Remove needless CPU up quiescent state report Frederic Weisbecker
2025-03-14 14:36 ` [PATCH 4/5] rcu/exp: Warn on QS requested on dying CPU Frederic Weisbecker
2025-03-18 17:21   ` Paul E. McKenney
2025-03-19  9:14     ` Frederic Weisbecker
2025-03-14 14:36 ` [PATCH 5/5] rcu/exp: Warn on CPU lagging for too long within hotplug IPI's blindspot Frederic Weisbecker
2025-03-18 17:22   ` Paul E. McKenney
2025-03-19  9:42     ` Frederic Weisbecker
2025-03-19 14:04       ` Paul E. McKenney
  -- strict thread matches above, loose matches on Subject: below --
2025-04-29 13:42 [PATCH 0/5 v3] rcu/exp updates Frederic Weisbecker
2025-04-29 13:43 ` [PATCH 2/5] rcu/exp: Remove confusing needless full barrier on task unblock Frederic Weisbecker

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=20250314143642.72554-3-frederic@kernel.org \
    --to=frederic@kernel.org \
    --cc=boqun.feng@gmail.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neeraj.upadhyay@amd.com \
    --cc=paulmck@kernel.org \
    --cc=qiang.zhang1211@gmail.com \
    --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 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.