All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Neeraj Upadhyay <neeraju@codeaurora.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 3/3] srcu: Fix broken node geometry after early ssp init
Date: Fri, 2 Apr 2021 08:03:57 -0700	[thread overview]
Message-ID: <20210402150357.GQ2696@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20210402100221.GA134532@lothringen>

On Fri, Apr 02, 2021 at 12:02:21PM +0200, Frederic Weisbecker wrote:
> On Thu, Apr 01, 2021 at 06:12:41PM -0700, Paul E. McKenney wrote:
> > On Fri, Apr 02, 2021 at 01:47:04AM +0200, Frederic Weisbecker wrote:
> gg> >  void __init srcu_init(void)
> > >  {
> > > -	struct srcu_struct *ssp;
> > > +	static struct srcu_data __initdata old_sdp;
> > > +	static struct srcu_node __initdata old_mynode;
> > > +	struct srcu_struct *ssp, *tmp;
> > >  
> > >  	srcu_init_done = true;
> > > -	while (!list_empty(&srcu_boot_list)) {
> > > -		ssp = list_first_entry(&srcu_boot_list, struct srcu_struct,
> > > -				      work.work.entry);
> > > +	/*
> > > +	 * ssp's that got initialized before rcu_init_geometry() have a stale
> > > +	 * node hierarchy. Rebuild their node trees and propagate states from
> > > +	 * pruned leaf nodes.
> > > +	 */
> > > +	list_for_each_entry_safe(ssp, tmp, &srcu_early_init_list, early_init) {
> > > +		struct srcu_data *sdp = this_cpu_ptr(ssp->sda);
> > > +
> > > +		list_del(&ssp->early_init);
> > > +		old_sdp = *sdp;
> > > +		old_mynode = *sdp->mynode;
> > > +		init_srcu_struct_nodes(ssp);
> > > +		restore_srcu_sdp(sdp, &old_sdp, &old_mynode);
> > 
> > Why not just pull all of the pre-initialization callbacks onto a local
> > list (re-initialization the rcu_segcblist structures if necessary),
> > then iterate through that list re-invoking call_srcu() on each?
> > There shouldn't be that many pre-initialization call_srcu() invocations,
> > and if someday there are, it would not be hard to make __call_srcu()
> > take lists of callbacks and a count instead of a single callback, correct?
> > 
> > Or am I once again missing something basic?
> 
> So that would work for callbacks based started grace periods but not for the
> others. So if anybody calls start_poll_synchronize_rcu() early, simply requeuing
> the callbacks won't help. Even worse, a blind reinitialization of the ssp would
> lose the started grace period and a future poll_state_synchronize_rcu() might
> never succeed.

Good point...

> Arguably that's a quite a corner case and I don't expect anyone to call
> start_poll_synchronize_srcu() so early but who knows. An alternative is to
> forbid it and warn if used before srcu is initialized.

Another approach would be to have start_poll_synchronize_rcu() check to
see if initialization has happened, and if not, simply queue a callback.

Any other ways to make this work?

							Thanx, Paul

  reply	other threads:[~2021-04-02 15:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 23:47 [PATCH 0/3] srcu: Fix boot stall Frederic Weisbecker
2021-04-01 23:47 ` [PATCH 1/3] srcu: Remove superfluous ssp initialization on deferred work queue Frederic Weisbecker
2021-04-02  0:48   ` Paul E. McKenney
2021-04-02  0:58     ` Frederic Weisbecker
2021-04-02  1:19       ` Paul E. McKenney
2021-04-02  1:01     ` Paul E. McKenney
2021-04-01 23:47 ` [PATCH 2/3] srcu: Remove superfluous sdp->srcu_lock_count zero filling Frederic Weisbecker
2021-04-02  0:58   ` Paul E. McKenney
2021-04-01 23:47 ` [PATCH 3/3] srcu: Fix broken node geometry after early ssp init Frederic Weisbecker
2021-04-02  1:12   ` Paul E. McKenney
2021-04-02 10:02     ` Frederic Weisbecker
2021-04-02 15:03       ` Paul E. McKenney [this message]
2021-04-02 20:50         ` Frederic Weisbecker
2021-04-02 22:12           ` 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=20210402150357.GQ2696@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=boqun.feng@gmail.com \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neeraju@codeaurora.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.