All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: "Zhang, Qiang" <Qiang.Zhang@windriver.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>, rcu <rcu@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: RCU:  Question   rcu_preempt_blocked_readers_cgp  in rcu_gp_fqs_loop func
Date: Mon, 14 Sep 2020 16:06:36 -0400	[thread overview]
Message-ID: <20200914200636.GB2579423@google.com> (raw)
In-Reply-To: <20200909112241.GE29330@paulmck-ThinkPad-P72>

On Wed, Sep 09, 2020 at 04:22:41AM -0700, Paul E. McKenney wrote:
> On Wed, Sep 09, 2020 at 07:03:39AM +0000, Zhang, Qiang wrote:
> > 
> > When config preempt RCU,  and then  there are multiple levels  node,  the current task is preempted  in rcu  read critical region.
> > the current task be add to "rnp->blkd_tasks" link list,  and the "rnp->gp_tasks"  may be assigned a value .  these rnp is leaf node in RCU tree.
> > 
> > But in "rcu_gp_fqs_loop" func, we check blocked readers in root node. 
> > 
> > static void rcu_gp_fqs_loop(void)
> >  {
> >             .....
> >             struct rcu_node *rnp = rcu_get_root();
> >             .....
> >             if (!READ_ONCE(rnp->qsmask) &&
> >                                !rcu_preempt_blocked_readers_cgp(rnp))    ------> rnp is root node
> >                      break;
> >             ....
> > }
> > 
> > the root node's blkd_tasks never add task, the "rnp->gp_tasks" is never be assigned value,  this check is invailed.
> >  Should we check leaf nodes like this 
> 
> There are two cases:
> 
> 1.	There is only a single rcu_node structure, which is both root
> 	and leaf.  In this case, the current check is required:  Both
> 	->qsmask and the ->blkd_tasks list must be checked.  Your
> 	rcu_preempt_blocked_readers() would work in this case, but
> 	the current code is a bit faster because it does not need
> 	to acquire the ->lock nor does it need the loop overhead.
> 
> 2.	There are multiple levels.  In this case, as you say, the root
> 	rcu_node structure's ->blkd_tasks list will always be empty.
> 	But also in this case, the root rcu_node structure's ->qsmask
> 	cannot be zero until all the leaf rcu_node structures' ->qsmask
> 	fields are zero and their ->blkd_tasks lists no longer have
> 	tasks blocking the current grace period.  This means that your
> 	rcu_preempt_blocked_readers() function would never return
> 	true in this case.
> 
> So the current code is fine.
> 
> Are you seeing failures on mainline kernels?  If so, what is the failure
> mode?

Nice question! He had me wondering there too for a bit ;-)

Thanks,

 - Joel


  parent reply	other threads:[~2020-09-14 20:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-14  6:45 [PATCH] rcu: shrink each possible cpu krcp qiang.zhang
2020-08-14 18:51 ` Uladzislau Rezki
2020-08-17 22:03   ` Joel Fernandes
2020-08-18 17:18     ` Paul E. McKenney
2020-08-18 19:00       ` Joel Fernandes
2020-08-18 21:03         ` Paul E. McKenney
2020-08-18 21:55           ` Uladzislau Rezki
2020-08-18 22:02             ` Paul E. McKenney
2020-08-19  0:04               ` Joel Fernandes
2020-08-19  3:00                 ` 回复: " Zhang, Qiang
2020-08-19 13:04                   ` Paul E. McKenney
2020-08-19 13:56                   ` Joel Fernandes
2020-08-19 15:21                     ` Paul E. McKenney
2020-08-19 15:54                       ` Joel Fernandes
2020-08-19 15:58                       ` Uladzislau Rezki
2020-08-20 22:39                         ` Joel Fernandes
2020-08-21 15:33                           ` Paul E. McKenney
2020-08-31  9:30                             ` Uladzislau Rezki
2020-09-09  6:35                             ` Zhang, Qiang
2020-09-09  7:03                               ` RCU: Question rcu_preempt_blocked_readers_cgp in rcu_gp_fqs_loop func Zhang, Qiang
2020-09-09 11:22                                 ` Paul E. McKenney
2020-09-10  3:25                                   ` 回复: " Zhang, Qiang
2020-09-14 20:06                                   ` Joel Fernandes [this message]
2020-08-19 11:22                 ` [PATCH] rcu: shrink each possible cpu krcp Uladzislau Rezki
2020-08-19 13:25                   ` Joel Fernandes
2020-08-18 23:25             ` Joel Fernandes

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=20200914200636.GB2579423@google.com \
    --to=joel@joelfernandes.org \
    --cc=Qiang.Zhang@windriver.com \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.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.