diff options
| author | Frederic Weisbecker <frederic@kernel.org> | 2025-04-29 16:43:01 +0300 |
|---|---|---|
| committer | Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org> | 2025-07-08 20:50:19 +0300 |
| commit | 4b9432ed65cb3a692e8d8bd86abb93f5f2dc5b69 (patch) | |
| tree | a3ea1e00917f54b378b523b576b359afb3f79a09 /drivers/infiniband/hw/ionic/ionic_controlpath.c | |
| parent | f2e555fc04ba238cd1dd21040325fa0629ee433d (diff) | |
| download | linux-4b9432ed65cb3a692e8d8bd86abb93f5f2dc5b69.tar.xz | |
rcu/exp: Remove confusing needless full barrier on task unblock
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 across 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 superfluous. Therefore
remove it as it is confusing.
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Neeraj Upadhyay (AMD) <neeraj.upadhyay@kernel.org>
Diffstat (limited to 'drivers/infiniband/hw/ionic/ionic_controlpath.c')
0 files changed, 0 insertions, 0 deletions
