All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Dmitry Torokhov <dtor@chromium.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Stefan Wahren <stefan.wahren@i2se.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Nishanth Menon <nm@ti.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] PM / OPP: take RCU lock in dev_pm_opp_get_opp_count
Date: Wed, 17 Dec 2014 15:47:13 -0800	[thread overview]
Message-ID: <20141217234713.GT5310@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAKohpok0UieH=Pi4nU2tKqV1_LH+3uzMDr0B8wsN61g1BnG4pg@mail.gmail.com>

On Wed, Dec 17, 2014 at 10:06:17AM +0530, Viresh Kumar wrote:
> On 17 December 2014 at 04:39, Dmitry Torokhov <dtor@chromium.org> wrote:
> > A lot of callers are missing the fact that dev_pm_opp_get_opp_count
> > needs to be called under RCU lock. Given that RCU locks can safely be
> > nested, instead of providing *_locked() API, let's take RCU lock inside
> 
> Hmm, I asked for a *_locked() API because many users of
> dev_pm_opp_get_opp_count() are already calling it from rcu read side
> critical sections.
> 
> Now, there are two questions:
> - Can rcu-read side critical sections be nested ?
> 
> Yes, this is what the comment over rcu_read_lock() says
> 
>  * RCU read-side critical sections may be nested.  Any deferred actions
>  * will be deferred until the outermost RCU read-side critical section
>  * completes.
> 
> - Would it be better to drop these double rcu_read_locks() ? i.e. either
> get a *_locked() API or fix the callers of dev_pm_opp_get_opp_count().
> 
> @Paul: What do you say ?

Yep, they can be nested.  Both rcu_read_lock() and rcu_read_unlock()
are quite fast, as are their friends, so there is almost no performance
penalty from nesting.  So the decision normally turns on maintainability
and style.

							Thanx, Paul

> > dev_pm_opp_get_opp_count() and leave callers as is.
> >
> > Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
> > ---
> >  drivers/base/power/opp.c | 15 ++++++++-------
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> > index 413c7fe..ee5eca2 100644
> > --- a/drivers/base/power/opp.c
> > +++ b/drivers/base/power/opp.c
> > @@ -216,9 +216,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq);
> >   * This function returns the number of available opps if there are any,
> >   * else returns 0 if none or the corresponding error value.
> >   *
> > - * Locking: This function must be called under rcu_read_lock(). This function
> > - * internally references two RCU protected structures: device_opp and opp which
> > - * are safe as long as we are under a common RCU locked section.
> > + * Locking: This function takes rcu_read_lock().
> >   */
> >  int dev_pm_opp_get_opp_count(struct device *dev)
> >  {
> > @@ -226,13 +224,14 @@ int dev_pm_opp_get_opp_count(struct device *dev)
> >         struct dev_pm_opp *temp_opp;
> >         int count = 0;
> >
> > -       opp_rcu_lockdep_assert();
> > +       rcu_read_lock();
> >
> >         dev_opp = find_device_opp(dev);
> >         if (IS_ERR(dev_opp)) {
> > -               int r = PTR_ERR(dev_opp);
> > -               dev_err(dev, "%s: device OPP not found (%d)\n", __func__, r);
> > -               return r;
> > +               count = PTR_ERR(dev_opp);
> > +               dev_err(dev, "%s: device OPP not found (%d)\n",
> > +                       __func__, count);
> > +               goto out_unlock;
> >         }
> >
> >         list_for_each_entry_rcu(temp_opp, &dev_opp->opp_list, node) {
> > @@ -240,6 +239,8 @@ int dev_pm_opp_get_opp_count(struct device *dev)
> >                         count++;
> >         }
> >
> > +out_unlock:
> > +       rcu_read_unlock();
> >         return count;
> >  }
> 
> Looked fine otherwise:
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> 


  parent reply	other threads:[~2014-12-17 23:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16 23:09 [PATCH 0/4] Allow cpufreq-dt to defer probe if OPP table is not ready Dmitry Torokhov
2014-12-16 23:09 ` [PATCH 1/4] PM / OPP: add some lockdep annotations Dmitry Torokhov
2014-12-17  4:10   ` Viresh Kumar
2014-12-24 16:28   ` Nishanth Menon
2014-12-24 16:28     ` Nishanth Menon
2014-12-16 23:09 ` [PATCH 2/4] PM / OPP: fix warning in of_free_opp_table Dmitry Torokhov
2014-12-17  4:28   ` Viresh Kumar
2014-12-24 16:42     ` Nishanth Menon
2014-12-16 23:09 ` [PATCH 3/4] PM / OPP: take RCU lock in dev_pm_opp_get_opp_count Dmitry Torokhov
2014-12-17  4:36   ` Viresh Kumar
2014-12-17 17:28     ` Dmitry Torokhov
2014-12-18  2:11       ` Viresh Kumar
2014-12-17 23:47     ` Paul E. McKenney [this message]
2014-12-18  2:11       ` Viresh Kumar
2014-12-24 16:48   ` Nishanth Menon
2014-12-24 16:48     ` Nishanth Menon
2014-12-24 17:09     ` Dmitry Torokhov
2014-12-24 17:16       ` Nishanth Menon
2014-12-24 17:31         ` Dmitry Torokhov
2014-12-24 17:37           ` Nishanth Menon
2014-12-24 17:44             ` Dmitry Torokhov
2014-12-24 20:37               ` Nishanth Menon
2014-12-27 20:34                 ` Rafael J. Wysocki
2014-12-16 23:09 ` [PATCH 4/4] cpufreq-dt: defer probing if OPP table is not ready Dmitry Torokhov
2014-12-17  4:37   ` Viresh Kumar
2014-12-24 16:58     ` Nishanth Menon
2014-12-17  4:42 ` [PATCH 0/4] Allow cpufreq-dt to defer probe " Viresh Kumar

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=20141217234713.GT5310@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=dtor@chromium.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=rjw@rjwysocki.net \
    --cc=stefan.wahren@i2se.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=viresh.kumar@linaro.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 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.