All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Neeraj upadhyay <neeraj.iitr10@gmail.com>
Cc: Joel Fernandes <joel@joelfernandes.org>,
	zhuangel570 <zhuangel570@gmail.com>,
	paulmck@kernel.org, rcu@vger.kernel.org, josh@joshtriplett.org,
	rostedt@goodmis.org, mathieu.desnoyers@efficios.com,
	jiangshanlai@gmail.com, like.xu.linux@gmail.com,
	linussli@tencent.com, foxywang@tencent.com
Subject: Re: SRCU: kworker hung in synchronize_srcu
Date: Tue, 3 Oct 2023 14:22:01 +0200	[thread overview]
Message-ID: <ZRwHadV/p6f7RzGn@lothringen> (raw)
In-Reply-To: <ZRsxk_fZZoUGJ_my@localhost.localdomain>

On Mon, Oct 02, 2023 at 11:09:39PM +0200, Frederic Weisbecker wrote:
> > >         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);
> > > @@ -1245,7 +1243,18 @@ static unsigned long srcu_gp_start_if_needed(struct srcu_struct *ssp,
> > >         rcu_segcblist_advance(&sdp->srcu_cblist,
> > >                               rcu_seq_current(&ssp->srcu_sup->srcu_gp_seq));
> > >         s = rcu_seq_snap(&ssp->srcu_sup->srcu_gp_seq);
> > > -       (void)rcu_segcblist_accelerate(&sdp->srcu_cblist, s);
> > > +       /*
> > > +        * Acceleration might fail if the preceding call to
> > > +        * rcu_segcblist_advance() also failed due to a prior grace
> > > +        * period seen incomplete before rcu_seq_snap(). If so then a new
> > > +        * call to advance will see the completed grace period and fix
> > > +        * the situation.
> > > +        */
> > > +       if (!rcu_segcblist_accelerate(&sdp->srcu_cblist, s)) {
> > 
> > We can add below also? Here old and new are rcu_seq_current() values used in
> > the 2 calls to rcu_segcblist_advance().
> > 
> > WARN_ON_ONCE(!(rcu_seq_completed_gp(old, new) && rcu_seq_new_gp(old, new)));
> 
> Very good point! "new" should be exactly one and a half grace period away from
> "old", will add that.
> 
> Cooking proper patches now.

Actually this more simple fix below. rcu_seq_snap() can be called before
rcu_segcblist_advance() after all. The only side effect is that callbacks
advancing is then _after_ the full barrier in rcu_seq_snap(). I don't see
an obvious problem with that as that barrier only cares about:

1) Ordering accesses of the update side before call_srcu() so they don't bleed
2) See all the accesses prior to the grace period of the current gp_num

The only things callbacks advancing need to be ordered against are carried by
snp locking.

I still remove the accelerations elsewhere and advancing in srcu_gp_start() in
further patches. I'll also avoid advancing and acceleration in
srcu_gp_start_if_needed if there is no callback to queue.

The point is also that this simple fix alone can be easily backported and
the rest can come as cleanups.


diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index 5602042856b1..8b09fb37dbf3 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -1244,10 +1244,10 @@ static unsigned long srcu_gp_start_if_needed(struct srcu_struct *ssp,
 	spin_lock_irqsave_sdp_contention(sdp, &flags);
 	if (rhp)
 		rcu_segcblist_enqueue(&sdp->srcu_cblist, rhp);
+	s = rcu_seq_snap(&ssp->srcu_sup->srcu_gp_seq);
 	rcu_segcblist_advance(&sdp->srcu_cblist,
 			      rcu_seq_current(&ssp->srcu_sup->srcu_gp_seq));
-	s = rcu_seq_snap(&ssp->srcu_sup->srcu_gp_seq);
-	(void)rcu_segcblist_accelerate(&sdp->srcu_cblist, s);
+	WARN_ON_ONCE(!rcu_segcblist_accelerate(&sdp->srcu_cblist, s) && rhp);
 	if (ULONG_CMP_LT(sdp->srcu_gp_seq_needed, s)) {
 		sdp->srcu_gp_seq_needed = s;
 		needgp = true;

  parent reply	other threads:[~2023-10-03 12:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28  7:59 SRCU: kworker hung in synchronize_srcu zhuangel570
2023-09-28 21:39 ` Joel Fernandes
2023-09-28 21:40   ` Joel Fernandes
2023-09-29  1:50   ` Zhouyi Zhou
2023-09-29 22:44   ` Frederic Weisbecker
2023-09-30  2:45     ` Neeraj upadhyay
2023-09-30  7:30       ` Frederic Weisbecker
2023-09-30  9:10       ` Frederic Weisbecker
2023-09-30  9:48         ` Neeraj upadhyay
2023-09-30 10:01   ` Neeraj upadhyay
2023-10-01  0:19     ` Joel Fernandes
2023-10-01  2:27       ` Neeraj upadhyay
2023-10-01 22:32         ` Frederic Weisbecker
2023-10-01 22:39           ` Frederic Weisbecker
2023-10-02  2:21             ` Neeraj upadhyay
2023-10-02 11:05               ` Frederic Weisbecker
2023-10-02 22:46               ` Frederic Weisbecker
2023-10-03 12:06                 ` Neeraj upadhyay
2023-10-02  2:17           ` Neeraj upadhyay
2023-10-02 10:41             ` Frederic Weisbecker
2023-10-02 13:22               ` Neeraj upadhyay
2023-10-02 21:09                 ` Frederic Weisbecker
2023-10-03 12:00                   ` Neeraj upadhyay
2023-10-03 12:22                   ` Frederic Weisbecker [this message]
2023-10-03 18:46                     ` Neeraj upadhyay
2023-10-07  9:13         ` zhuangel570
2023-10-07  8:53   ` zhuangel570
2023-09-30 10:11 ` Neeraj upadhyay

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=ZRwHadV/p6f7RzGn@lothringen \
    --to=frederic@kernel.org \
    --cc=foxywang@tencent.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=like.xu.linux@gmail.com \
    --cc=linussli@tencent.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=neeraj.iitr10@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --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 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.