[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <60b611ac-69e0-1339-599a-299483b6df3d@collabora.com>
Date: Tue, 3 Jul 2018 15:16:35 +0200
From: Enric Balletbo i Serra <enric.balletbo@...labora.com>
To: myungjoo.ham@...sung.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: "kernel@...labora.com" <kernel@...labora.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v3] PM / devfreq: Fix devfreq_add_device() when drivers
are built as modules.
Hi MyungJoo
On 03/07/18 12:57, MyungJoo Ham wrote:
>> @@ -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;
>> --
>
> The possibility that the result of try_then_request_governor is
> not kept protected until the line of
> "if (df->governor == governor)" is itching.
>
> Can you make it kept "locked" from the return of
> find_devfreq_governor() (either in try_then... or in this function)
> to the unlock of governor_store()?
>
Sure, I'll send v4 in a minute.
Thanks,
Enric
>
> Cheers,
> MyungJoo
>
Powered by blists - more mailing lists