From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>,
Uladzislau Rezki <urezki@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>, rcu <rcu@vger.kernel.org>
Subject: Re: [PATCH 1/3] rcu/exp: Protect against early QS report
Date: Thu, 13 Mar 2025 17:40:19 +0100 [thread overview]
Message-ID: <Z9MKc7hlZFgLr_jM@localhost.localdomain> (raw)
In-Reply-To: <abaf4f7f-42b3-43ff-888c-369501b0b4c6@paulmck-laptop>
Le Fri, Feb 14, 2025 at 01:10:43AM -0800, Paul E. McKenney a écrit :
> On Fri, Feb 14, 2025 at 12:25:57AM +0100, Frederic Weisbecker wrote:
> > When a grace period is started, the ->expmask of each node is set up
> > from sync_exp_reset_tree(). Then later on each leaf node also initialize
> > its ->exp_tasks pointer.
> >
> > This means that the initialization of the quiescent state of a node and
> > the initialization of its blocking tasks happen with an unlocked node
> > gap in-between.
> >
> > It happens to be fine because nothing is expected to report an exp
> > quiescent state within this gap, since no IPI have been issued yet and
> > every rdp's ->cpu_no_qs.b.exp should be false.
> >
> > However if it were to happen by accident, the quiescent state could be
> > reported and propagated while ignoring tasks that blocked _before_ the
> > start of the grace period.
> >
> > Prevent such trouble to happen in the future and initialize both the
> > quiescent states mask to report and the blocked tasks head from the same
> > node locked block.
> >
> > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
>
> Thank you for looking into this!
>
> One question: What happens if a CPU has tasks pending during the
> call to sync_exp_reset_tree(), but all of these tasks complete
> their RCU read-side critical sections before execution reaches
> __sync_rcu_exp_select_node_cpus()?
>
> (My guess is that all is well, but even if so, it would be good to record
> why in the commit log.)
All is (expected to be) well because the QS won't be reported yet:
rdp->cpu_no_qs.b.exp is still false, therefore rnp->expmask will
still have the RDPs masks set.
!PREEMPT_RCU is different because sync_sched_exp_online_cleanup()
can report the QS earlier. But that patch is a PREEMPT_RCU concern
only.
I'll drop a note on the changelog.
Thanks.
>
> Thanx, Paul
>
> > ---
> > kernel/rcu/tree_exp.h | 14 +++++++-------
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> > index 8d4895c854c5..caff16e441d1 100644
> > --- a/kernel/rcu/tree_exp.h
> > +++ b/kernel/rcu/tree_exp.h
> > @@ -141,6 +141,13 @@ static void __maybe_unused sync_exp_reset_tree(void)
> > raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > WARN_ON_ONCE(rnp->expmask);
> > WRITE_ONCE(rnp->expmask, rnp->expmaskinit);
> > + /*
> > + * Need to wait for any blocked tasks as well. Note that
> > + * additional blocking tasks will also block the expedited GP
> > + * until such time as the ->expmask bits are cleared.
> > + */
> > + if (rcu_is_leaf_node(rnp) && rcu_preempt_has_tasks(rnp))
> > + WRITE_ONCE(rnp->exp_tasks, rnp->blkd_tasks.next);
> > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > }
> > }
> > @@ -393,13 +400,6 @@ static void __sync_rcu_exp_select_node_cpus(struct rcu_exp_work *rewp)
> > }
> > mask_ofl_ipi = rnp->expmask & ~mask_ofl_test;
> >
> > - /*
> > - * Need to wait for any blocked tasks as well. Note that
> > - * additional blocking tasks will also block the expedited GP
> > - * until such time as the ->expmask bits are cleared.
> > - */
> > - if (rcu_preempt_has_tasks(rnp))
> > - WRITE_ONCE(rnp->exp_tasks, rnp->blkd_tasks.next);
> > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> >
> > /* IPI the remaining CPUs for expedited quiescent state. */
> > --
> > 2.46.0
> >
next prev parent reply other threads:[~2025-03-13 16:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 23:25 [PATCH 0/3] rcu/exp updates Frederic Weisbecker
2025-02-13 23:25 ` [PATCH 1/3] rcu/exp: Protect against early QS report Frederic Weisbecker
2025-02-14 9:10 ` Paul E. McKenney
2025-03-13 16:40 ` Frederic Weisbecker [this message]
2025-03-13 17:04 ` Paul E. McKenney
2025-02-13 23:25 ` [PATCH 2/3] rcu/exp: Remove confusing needless full barrier on task unblock Frederic Weisbecker
2025-02-25 21:59 ` Joel Fernandes
2025-02-26 0:08 ` Paul E. McKenney
2025-02-26 12:52 ` Frederic Weisbecker
2025-02-26 15:04 ` Paul E. McKenney
2025-02-26 15:26 ` Joel Fernandes
2025-02-26 15:34 ` Frederic Weisbecker
2025-02-13 23:25 ` [PATCH 3/3] rcu/exp: Remove needless CPU up quiescent state report Frederic Weisbecker
2025-02-14 9:01 ` Paul E. McKenney
2025-02-14 12:10 ` Frederic Weisbecker
2025-02-15 10:38 ` Paul E. McKenney
2025-02-15 22:23 ` Frederic Weisbecker
2025-02-19 14:58 ` Paul E. McKenney
2025-02-19 15:55 ` Paul E. McKenney
2025-02-21 15:31 ` Frederic Weisbecker
2025-02-21 15:52 ` Frederic Weisbecker
2025-02-26 0:00 ` Paul E. McKenney
2025-03-03 20:10 ` Paul E. McKenney
2025-03-14 14:39 ` Frederic Weisbecker
2025-03-18 17:07 ` 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=Z9MKc7hlZFgLr_jM@localhost.localdomain \
--to=frederic@kernel.org \
--cc=boqun.feng@gmail.com \
--cc=joel@joelfernandes.org \
--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.