From: Viresh Kumar <viresh.kumar@linaro.org>
To: Juri Lelli <juri.lelli@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
peterz@infradead.org, rjw@rjwysocki.net, mturquette@baylibre.com,
steve.muckle@linaro.org, vincent.guittot@linaro.org,
morten.rasmussen@arm.com, dietmar.eggemann@arm.com
Subject: Re: [RFC PATCH 05/19] cpufreq: assert locking when accessing cpufreq_policy_list
Date: Wed, 13 Jan 2016 11:29:17 +0530 [thread overview]
Message-ID: <20160113055917.GG6050@ubuntu> (raw)
In-Reply-To: <20160112114454.GB7015@e106622-lin>
On 12-01-16, 11:44, Juri Lelli wrote:
> But next_policy is called multiple times as part of
> for_each_suitable_policy(). What if someone thinks she/he can release
> cpufreq_driver_lock inside for_each_(in)active_policy() loop? Not that
> it makes sense, but don't you think it could happen?
Okay, I don't have strong opinion about using that only in the first
routine. No issues.
> > > /* No policies in the list */
> > > if (list_empty(&cpufreq_policy_list))
> > > return NULL;
> > > @@ -2430,6 +2432,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
> > > if (ret)
> > > goto err_boost_unreg;
> > >
> > > + lockdep_assert_held(&cpufreq_driver_lock);
> >
> > Why do you need a cpufreq_driver_lock here? And the above change
> > should generate a lockdep here as the lock isn't taken right now.
> >
>
> Because you are checking cpufreq_policy_list to see if it's empty. And
> it generates a lockdep warning, yes; fixed by next patch. Maybe putting
> fixes before warnings, as you are suggesting, is better.
Well, locking isn't required because we think we need to protect every
access of a variable (like cpufreq_policy_list here). But we need to
protect its access from possible races.
What I am saying is, we can't have a race here. And so no need to lock
it down.
--
viresh
next prev parent reply other threads:[~2016-01-13 5:59 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-11 17:35 [RFC PATCH 00/19] cpufreq locking cleanups and documentation Juri Lelli
2016-01-11 17:35 ` [RFC PATCH 01/19] cpufreq: do not expose cpufreq_governor_lock Juri Lelli
2016-01-12 8:56 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 02/19] cpufreq: merge governor lock and mutex Juri Lelli
2016-01-12 9:00 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 03/19] cpufreq: kill for_each_policy Juri Lelli
2016-01-12 9:01 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 04/19] cpufreq: bring data structures close to their locks Juri Lelli
2016-01-11 22:05 ` Peter Zijlstra
2016-01-11 23:03 ` Rafael J. Wysocki
2016-01-12 8:27 ` Peter Zijlstra
2016-01-12 10:43 ` Juri Lelli
2016-01-12 16:47 ` Rafael J. Wysocki
2016-01-11 22:07 ` Peter Zijlstra
2016-01-12 9:27 ` Viresh Kumar
2016-01-12 11:21 ` Juri Lelli
2016-01-12 11:58 ` Peter Zijlstra
2016-01-12 12:36 ` Juri Lelli
2016-01-12 15:26 ` Juri Lelli
2016-01-12 15:58 ` Peter Zijlstra
2016-01-12 9:10 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 05/19] cpufreq: assert locking when accessing cpufreq_policy_list Juri Lelli
2016-01-12 9:34 ` Viresh Kumar
2016-01-12 11:44 ` Juri Lelli
2016-01-13 5:59 ` Viresh Kumar [this message]
2016-01-11 17:35 ` [RFC PATCH 06/19] cpufreq: always access cpufreq_policy_list while holding cpufreq_driver_lock Juri Lelli
2016-01-12 9:57 ` Viresh Kumar
2016-01-12 12:08 ` Juri Lelli
2016-01-13 6:01 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 07/19] cpufreq: assert locking when accessing cpufreq_governor_list Juri Lelli
2016-01-12 10:01 ` Viresh Kumar
2016-01-12 15:33 ` Juri Lelli
2016-01-11 17:35 ` [RFC PATCH 08/19] cpufreq: fix warning for cpufreq_init_policy unlocked access to cpufreq_governor_list Juri Lelli
2016-01-12 10:09 ` Viresh Kumar
2016-01-12 15:52 ` Juri Lelli
2016-01-13 6:07 ` Viresh Kumar
2016-01-14 16:35 ` Juri Lelli
2016-01-18 5:23 ` Viresh Kumar
2016-01-18 15:19 ` Juri Lelli
2016-01-11 17:35 ` [RFC PATCH 09/19] cpufreq: fix warning for show_scaling_available_governors " Juri Lelli
2016-01-12 10:13 ` Viresh Kumar
2016-01-13 10:25 ` Juri Lelli
2016-01-13 10:32 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 10/19] cpufreq: assert policy->rwsem is held in cpufreq_set_policy Juri Lelli
2016-01-12 10:15 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor Juri Lelli
2016-01-12 10:20 ` Viresh Kumar
2016-01-30 0:33 ` Saravana Kannan
2016-01-30 11:49 ` Rafael J. Wysocki
2016-02-01 6:09 ` Viresh Kumar
2016-02-01 10:22 ` Rafael J. Wysocki
2016-02-01 20:24 ` Saravana Kannan
2016-02-01 21:00 ` Rafael J. Wysocki
2016-02-02 6:36 ` Viresh Kumar
2016-02-02 21:38 ` Saravana Kannan
2016-02-02 6:34 ` Viresh Kumar
2016-02-02 21:37 ` Saravana Kannan
2016-02-03 2:13 ` Viresh Kumar
2016-02-03 4:04 ` Saravana Kannan
2016-02-03 5:02 ` Viresh Kumar
2016-02-03 5:06 ` Saravana Kannan
2016-02-03 6:59 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 12/19] cpufreq: fix locking of policy->rwsem in cpufreq_init_policy Juri Lelli
2016-01-12 10:39 ` Viresh Kumar
2016-01-14 17:58 ` Juri Lelli
2016-01-11 17:35 ` [RFC PATCH 13/19] cpufreq: fix locking of policy->rwsem in cpufreq_offline_prepare Juri Lelli
2016-01-12 10:54 ` Viresh Kumar
2016-01-15 12:37 ` Juri Lelli
2016-01-11 17:35 ` [RFC PATCH 14/19] cpufreq: fix locking of policy->rwsem in cpufreq_offline_finish Juri Lelli
2016-01-12 11:02 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 15/19] cpufreq: remove useless usage of cpufreq_governor_mutex in __cpufreq_governor Juri Lelli
2016-01-12 11:06 ` Viresh Kumar
2016-01-15 16:30 ` Juri Lelli
2016-01-18 5:50 ` Viresh Kumar
2016-01-19 16:49 ` Juri Lelli
2016-01-20 7:29 ` Viresh Kumar
2016-01-20 10:17 ` Juri Lelli
2016-01-20 10:18 ` Viresh Kumar
2016-01-20 10:27 ` Juri Lelli
2016-01-20 10:30 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 16/19] cpufreq: hold policy->rwsem across CPUFREQ_GOV_POLICY_EXIT Juri Lelli
2016-01-12 11:09 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 17/19] cpufreq: stop checking for cpufreq_driver being present in cpufreq_cpu_get Juri Lelli
2016-01-12 11:17 ` Viresh Kumar
2016-01-11 17:35 ` [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli
2016-01-12 11:24 ` Viresh Kumar
2016-01-13 0:54 ` Michael Turquette
2016-01-13 6:31 ` Viresh Kumar
[not found] ` <20160113182131.1168.45753@quark.deferred.io>
2016-01-14 9:44 ` Juri Lelli
2016-01-14 10:32 ` Viresh Kumar
2016-01-14 13:52 ` Juri Lelli
2016-01-18 5:09 ` Viresh Kumar
2016-01-19 14:00 ` Peter Zijlstra
2016-01-19 14:42 ` Juri Lelli
2016-01-19 15:30 ` Peter Zijlstra
2016-01-19 16:01 ` Juri Lelli
2016-01-19 19:17 ` Peter Zijlstra
2016-01-19 19:21 ` Peter Zijlstra
2016-01-19 21:52 ` Rafael J. Wysocki
2016-01-20 17:04 ` Peter Zijlstra
2016-01-20 22:12 ` Rafael J. Wysocki
2016-01-20 22:38 ` Peter Zijlstra
2016-01-20 23:33 ` Rafael J. Wysocki
2016-01-20 12:59 ` Juri Lelli
2016-01-11 17:36 ` [RFC PATCH 19/19] cpufreq: documentation: document locking scheme Juri Lelli
2016-01-11 22:45 ` [RFC PATCH 00/19] cpufreq locking cleanups and documentation Rafael J. Wysocki
2016-01-12 10:46 ` Juri Lelli
2016-01-30 0:57 ` Saravana Kannan
2016-02-01 6:02 ` Viresh Kumar
2016-02-01 12:06 ` Juri Lelli
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=20160113055917.GG6050@ubuntu \
--to=viresh.kumar@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=mturquette@baylibre.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=steve.muckle@linaro.org \
--cc=vincent.guittot@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 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).