From: akhilpo@codeaurora.org
To: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>,
linux-kernel@vger.kernel.org, kernel@collabora.com,
Chanwoo Choi <cw00.choi@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
linux-pm@vger.kernel.org
Subject: Re: [PATCH v3] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.
Date: Sat, 23 Jun 2018 02:52:29 +0530 [thread overview]
Message-ID: <7c67974e40afd15abfca5907b27de097@codeaurora.org> (raw)
In-Reply-To: <1e792d3c972998f92109c127886243e32c4cde71.camel@collabora.com>
On 2018-06-22 22:43, Ezequiel Garcia wrote:
> Hey Akhil,
>
> On Fri, 2018-06-22 at 12:33 +0530, Akhil P Oommen wrote:
>> On 6/22/2018 6:41 AM, Ezequiel Garcia wrote:
>> > Hey Enric,
>> >
>> > On Fri, 2018-06-22 at 00:04 +0200, Enric Balletbo i Serra wrote:
>> > > When the devfreq driver and the governor driver are built as
>> > > modules,
>> > > the call to devfreq_add_device() or governor_store() fails
>> > > because
>> > > the
>> > > governor driver is not loaded at the time the devfreq driver
>> > > loads.
>> > > The
>> > > devfreq driver has a build dependency on the governor but also
>> > > should
>> > > have a runtime dependency. We need to make sure that the governor
>> > > driver
>> > > is loaded before the devfreq driver.
>> > >
>> > > This patch fixes this bug by adding a try_then_request_governor()
>> > > function. First tries to find the governor, and then, if it is
>> > > not
>> > > found,
>> > > it requests the module and tries again.
>> > >
>> > > Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to
>> > > governor
>> > > using name)
>> > > Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.c
>> > > om>
>> > > ---
>> > >
>> > > Changes in v3:
>> > > - Remove unneded change in dev_err message.
>> > > - Fix err returned value in case to not find the governor.
>> > >
>> > > Changes in v2:
>> > > - Add a new function to request the module and call that function
>> > > from
>> > > devfreq_add_device and governor_store.
>> > >
>> > > drivers/devfreq/devfreq.c | 65
>> > > ++++++++++++++++++++++++++++++++-----
>> > > --
>> >
>> > [snip snip]
>> > > - governor = find_devfreq_governor(devfreq-
>> > > >governor_name);
>> > > + governor = try_then_request_governor(devfreq-
>> > > > governor_name);
>> > >
>> > > if (IS_ERR(governor)) {
>> > > dev_err(dev, "%s: Unable to find governor for
>> > > the
>> > > device\n",
>> > > __func__);
>> > > err = PTR_ERR(governor);
>> > > - goto err_init;
>> > > + goto err_unregister;
>> > > }
>> > >
>> > > + mutex_lock(&devfreq_list_lock);
>> > > +
>> >
>> > I know it's not something we are introducing in this patch,
>> > but still... calling a hook with a mutex held looks
>> > fishy to me.
>> >
>> > This lock should only protect the list, unless I am missing
>> > something.
>> >
>> > > devfreq->governor = governor;
>> > > err = devfreq->governor->event_handler(devfreq,
>> > > DEVFREQ_GOV_START,
>> > > NULL);
>> > > @@ -663,14 +703,16 @@ struct devfreq *devfreq_add_device(struct
>> > > device *dev,
>> > > __func__);
>> > > goto err_init;
>> > > }
>> > > +
>> > > + list_add(&devfreq->node, &devfreq_list);
>> > > +
>> > > mutex_unlock(&devfreq_list_lock);
>> > >
>> > > return devfreq;
>> > >
>> > > err_init:
>> > > - list_del(&devfreq->node);
>> > > mutex_unlock(&devfreq_list_lock);
>> > > -
>> > > +err_unregister:
>> > > device_unregister(&devfreq->dev);
>> > > err_dev:
>> > > if (devfreq)
>> > > @@ -988,12 +1030,13 @@ static ssize_t governor_store(struct
>> > > device
>> > > *dev, struct device_attribute *attr,
>> > > if (ret != 1)
>> > > return -EINVAL;
>> > >
>> > > - mutex_lock(&devfreq_list_lock);
>> > > - governor = find_devfreq_governor(str_governor);
>> > > + governor = try_then_request_governor(str_governor);
>> > > if (IS_ERR(governor)) {
>> > > - ret = PTR_ERR(governor);
>> > > - goto out;
>> > > + return PTR_ERR(governor);
>> > > }
>> > > +
>> > > + mutex_lock(&devfreq_list_lock);
>> > > +
>> > > if (df->governor == governor) {
>> > > ret = 0;
>> > > goto out;
>> > > --
>> > > 2.17.1
>> > >
>> > >
>> >
>> > Regards,
>> > Eze
>>
>> Adding to Ezequiel's point, shouldn't we take more granular lock
>> (devfreq->lock) first and then call devfreq_list_lock at the time of
>> adding to the list?
>>
>
> Not sure why we should do that. devfreq->lock should be used to
> protect the struct devfreq state, while the devfreq_list_lock
> is apparently protecting the two lists (which seem unrelated
> lists).
>
> So, the two locks are not correlated.
>
> Regards,
> Eze
In governor_store(), we do 'df->governor = governor;' without taking
df->lock. So it is possible to switch governor while update_devfreq() is
in progress. I smell trouble there. Don't you think so?
I am assuming df->lock protects 'struct devfreq' and devfreq_list_lock
protects both device and governor lists.
-Akhil.
next prev parent reply other threads:[~2018-06-22 21:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-21 22:04 [PATCH v3] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules Enric Balletbo i Serra
2018-06-22 1:11 ` Ezequiel Garcia
2018-06-22 7:03 ` Akhil P Oommen
2018-06-22 8:22 ` Enric Balletbo i Serra
2018-06-22 9:06 ` Akhil P Oommen
2018-06-22 17:13 ` Ezequiel Garcia
2018-06-22 21:22 ` akhilpo [this message]
2018-07-03 10:15 ` Enric Balletbo Serra
[not found] ` <CGME20180622212233epcas2p3308116579442dc8a42a9db7445ce8ef8@epcms1p4>
2018-07-03 10:47 ` MyungJoo Ham
[not found] ` <CGME20180621220442epcas2p14960cff4b08825aceb9d0e7ff810aeae@epcms1p6>
2018-07-03 10:57 ` MyungJoo Ham
2018-07-03 13:16 ` Enric Balletbo i Serra
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=7c67974e40afd15abfca5907b27de097@codeaurora.org \
--to=akhilpo@codeaurora.org \
--cc=cw00.choi@samsung.com \
--cc=enric.balletbo@collabora.com \
--cc=ezequiel@collabora.com \
--cc=kernel@collabora.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=myungjoo.ham@samsung.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 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).