From: Boqun Feng <boqun.feng@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, rostedt@goodmis.org,
Brian Foster <bfoster@redhat.com>,
Dave Chinner <david@fromorbit.com>,
Al Viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>
Subject: Re: [PATCH rcu 04/12] rcu: Switch polled grace-period APIs to ->gp_seq_polled
Date: Wed, 20 Jul 2022 18:51:45 -0700 [thread overview]
Message-ID: <YtixMeMCcqAyeTiH@boqun-archlinux> (raw)
In-Reply-To: <20220721010455.GR1790663@paulmck-ThinkPad-P17-Gen-1>
On Wed, Jul 20, 2022 at 06:04:55PM -0700, Paul E. McKenney wrote:
[...]
> > > @@ -3860,7 +3944,7 @@ unsigned long get_state_synchronize_rcu(void)
> > > * before the load from ->gp_seq.
> > > */
> > > smp_mb(); /* ^^^ */
> > > - return rcu_seq_snap(&rcu_state.gp_seq);
> > > + return rcu_seq_snap(&rcu_state.gp_seq_polled);
> >
> > I happened to run into this. There is one usage of
> > get_state_synchronize_rcu() in start_poll_synchronize_rcu(), in which
> > the return value of get_state_synchronize_rcu() ("gp_seq") will be used
> > for rcu_start_this_gp(). I don't think this is quite right, because
> > after this change, rcu_state.gp_seq and rcu_state.gp_seq_polled are
> > different values, in fact ->gp_seq_polled is greater than ->gp_seq
> > by how many synchronize_rcu() is called in early boot.
> >
> > Am I missing something here?
>
> It does not appear that your are missing anything, sad to say!
>
> Does the following make it work better?
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 2122359f0c862..cf2fd58a93a41 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3571,7 +3571,7 @@ EXPORT_SYMBOL_GPL(get_state_synchronize_rcu);
> unsigned long start_poll_synchronize_rcu(void)
> {
> unsigned long flags;
> - unsigned long gp_seq = get_state_synchronize_rcu();
> + unsigned long gp_seq = rcu_seq_snap(&rcu_state.gp_seq);
get_state_synchronize_rcu() is still needed, because we need to return
a cookie for polling for this function. Something like below maybe? Hope
I didn't mess up the ordering ;-)
Regards,
Boqun
---------------
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 84d281776688..0f9134871289 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3571,11 +3583,39 @@ EXPORT_SYMBOL_GPL(get_state_synchronize_rcu);
unsigned long start_poll_synchronize_rcu(void)
{
unsigned long flags;
- unsigned long gp_seq = get_state_synchronize_rcu();
+ unsigned long gp_seq_poll = get_state_synchronize_rcu();
+ unsigned long gp_seq;
bool needwake;
struct rcu_data *rdp;
struct rcu_node *rnp;
+ /*
+ * Need to start a gp if no gp has been started yet.
+ *
+ * Note that we need to snapshot gp_seq after gp_seq_poll, otherwise
+ * consider the follow case:
+ *
+ * <no gp in progress> // gp# is 0
+ * snapshot gp_seq // gp #2 will be set as needed
+ * <a gp passed>
+ * // gp# is 1
+ * snapshot gp_seq_poll // polling gets ready until gp #3
+ *
+ * then the following rcu_start_this_gp() won't mark gp #3 as needed,
+ * and polling won't become ready if others don't start a gp.
+ *
+ * And the following case is fine:
+ *
+ * <no gp in progress> // gp# is 0
+ * snapshot gp_seq_poll // polling gets ready until gp #2
+ * <a gp passed>
+ * // gp# is 1
+ * snapshot gp_seq // gp #3 will be set as needed
+ *
+ * Also note, we rely on the smp_mb() in get_state_synchronize_rcu()
+ * to order the two snapshots.
+ */
+ gp_seq = rcu_seq_snap(&rcu_state.gp_seq);
lockdep_assert_irqs_enabled();
local_irq_save(flags);
rdp = this_cpu_ptr(&rcu_data);
@@ -3585,7 +3625,7 @@ unsigned long start_poll_synchronize_rcu(void)
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
if (needwake)
rcu_gp_kthread_wake();
- return gp_seq;
+ return gp_seq_poll;
}
EXPORT_SYMBOL_GPL(start_poll_synchronize_rcu);
next prev parent reply other threads:[~2022-07-21 1:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 22:49 [PATCH rcu 0/12] Polled grace-period updates for v5.20 Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 01/12] rcu: Make normal polling GP be more precise about sequence numbers Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 02/12] rcu: Provide a get_completed_synchronize_rcu() function Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 03/12] rcutorture: Validate get_completed_synchronize_rcu() Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 04/12] rcu: Switch polled grace-period APIs to ->gp_seq_polled Paul E. McKenney
2022-07-21 0:53 ` Boqun Feng
2022-07-21 1:04 ` Paul E. McKenney
2022-07-21 1:51 ` Boqun Feng [this message]
2022-07-21 4:47 ` Paul E. McKenney
2022-07-21 5:49 ` Boqun Feng
2022-07-22 1:03 ` Paul E. McKenney
2022-07-21 1:56 ` Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 05/12] rcu: Make polled grace-period API account for expedited grace periods Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 06/12] rcu: Make Tiny RCU grace periods visible to polled APIs Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 07/12] rcutorture: Verify that polled GP API sees synchronous grace periods Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 08/12] rcu: Add polled expedited grace-period primitives Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 09/12] rcutorture: Test " Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 10/12] rcu: Put panic_on_rcu_stall() after expedited RCU CPU stall warnings Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 11/12] rcu: Diagnose extended sync_rcu_do_polled_gp() loops Paul E. McKenney
2022-06-20 22:51 ` [PATCH rcu 12/12] rcu: Add irqs-disabled indicator to expedited RCU CPU stall warnings 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=YtixMeMCcqAyeTiH@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=raven@themaw.net \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=viro@zeniv.linux.org.uk \
/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.