From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>
Subject: Re: [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions
Date: Wed, 7 Mar 2018 07:48:29 -0800 [thread overview]
Message-ID: <20180307154829.GE3918@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180307084944.10229-1-boqun.feng@gmail.com>
On Wed, Mar 07, 2018 at 04:49:39PM +0800, Boqun Feng wrote:
> Since commit d9a3da0699b2 ("rcu: Add expedited grace-period support for
> preemptible RCU"), there are comments for some funtions in
> rcu_report_exp_rnp()'s call-chain saying that exp_mutex or its
> predecessors needs to be held.
>
> However, exp_mutex and its predecessors are merely used for synchronize
> between GPs, and it's clearly that all variables visited by those
> functions are under the protection of rcu_node's ->lock. Moreover, those
> functions are currently called without held exp_mutex, and seems that
> doesn't introduce any trouble.
>
> So this patch fix this problem by correcting the comments
>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> Fixes: d9a3da0699b2 ("rcu: Add expedited grace-period support for preemptible RCU")
Good catch, applied!
These have been around for almost a decade! ;-) They happened because
I ended up rewriting expedited support several times before it was
accepted, and apparently failed to update the comments towards the end.
So thank you for catching this one!
But wouldn't it be better to use lockdep instead of comments in this case?
Thanx, Paul
> ---
> kernel/rcu/tree_exp.h | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index f8e4571efabf..2fd882b08b7c 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -154,7 +154,7 @@ static void __maybe_unused sync_exp_reset_tree(struct rcu_state *rsp)
> * for the current expedited grace period. Works only for preemptible
> * RCU -- other RCU implementation use other means.
> *
> - * Caller must hold the rcu_state's exp_mutex.
> + * Caller must hold the specificed rcu_node structure's ->lock
> */
> static bool sync_rcu_preempt_exp_done(struct rcu_node *rnp)
> {
> @@ -170,8 +170,7 @@ static bool sync_rcu_preempt_exp_done(struct rcu_node *rnp)
> * recursively up the tree. (Calm down, calm down, we do the recursion
> * iteratively!)
> *
> - * Caller must hold the rcu_state's exp_mutex and the specified rcu_node
> - * structure's ->lock.
> + * Caller must hold the specified rcu_node structure's ->lock.
> */
> static void __rcu_report_exp_rnp(struct rcu_state *rsp, struct rcu_node *rnp,
> bool wake, unsigned long flags)
> @@ -207,8 +206,6 @@ static void __rcu_report_exp_rnp(struct rcu_state *rsp, struct rcu_node *rnp,
> /*
> * Report expedited quiescent state for specified node. This is a
> * lock-acquisition wrapper function for __rcu_report_exp_rnp().
> - *
> - * Caller must hold the rcu_state's exp_mutex.
> */
> static void __maybe_unused rcu_report_exp_rnp(struct rcu_state *rsp,
> struct rcu_node *rnp, bool wake)
> @@ -221,8 +218,7 @@ static void __maybe_unused rcu_report_exp_rnp(struct rcu_state *rsp,
>
> /*
> * Report expedited quiescent state for multiple CPUs, all covered by the
> - * specified leaf rcu_node structure. Caller must hold the rcu_state's
> - * exp_mutex.
> + * specified leaf rcu_node structure.
> */
> static void rcu_report_exp_cpu_mult(struct rcu_state *rsp, struct rcu_node *rnp,
> unsigned long mask, bool wake)
> --
> 2.16.2
>
next prev parent reply other threads:[~2018-03-07 15:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-07 8:49 [PATCH] rcu: exp: Fix "must hold exp_mutex" comments for QS reporting functions Boqun Feng
2018-03-07 15:48 ` Paul E. McKenney [this message]
2018-03-08 3:46 ` Boqun Feng
2018-03-08 4:30 ` Paul E. McKenney
2018-03-08 4:54 ` Boqun Feng
2018-03-08 8:30 ` Boqun Feng
2018-03-08 15:42 ` Paul E. McKenney
2018-03-09 6:57 ` Boqun Feng
2018-03-09 20:17 ` Paul E. McKenney
2018-03-12 5:28 ` Boqun Feng
2018-03-13 0:15 ` 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=20180307154829.GE3918@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=boqun.feng@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).