linux-kernel - Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <58228C10.3070502@samsung.com>
Date:   Wed, 09 Nov 2016 11:38:08 +0900
From:   Chanwoo Choi <cw00.choi@...sung.com>
To:     Saravana Kannan <skannan@...eaurora.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor
 fails to start

On 2016년 11월 09일 11:36, Chanwoo Choi wrote:
> Hi,
> 
> On 2016년 11월 09일 10:33, Chanwoo Choi wrote:
>> On 2016년 11월 09일 05:52, Saravana Kannan wrote:
>>> On 11/08/2016 01:02 AM, Chanwoo Choi wrote:
>>>> Hi,
>>>>
>>>> On 2016년 11월 08일 03:57, Saravana Kannan wrote:
>>>>> On 10/26/2016 05:06 PM, Chanwoo Choi wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 2016년 10월 27일 04:17, Saravana Kannan wrote:
>>>>>>> If the new governor fails to start, switch back to old governor so that the
>>>>>>> devfreq state is not left in some weird limbo.
>>>>>>>
>>>>>>> Signed-off-by: Saravana Kannan <skannan@...eaurora.org>
>>>>>>> ---
>>>>>>> * Fix NULL deref for real this time.
>>>>>>> * Addressed some style preferences.
>>>>>>>
>>>>>>>    drivers/devfreq/devfreq.c | 13 +++++++++++--
>>>>>>>    1 file changed, 11 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>>>>>> index bf3ea76..77c41a5 100644
>>>>>>> --- a/drivers/devfreq/devfreq.c
>>>>>>> +++ b/drivers/devfreq/devfreq.c
>>>>>>> @@ -919,7 +919,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
>>>>>>>        struct devfreq *df = to_devfreq(dev);
>>>>>>>        int ret;
>>>>>>>        char str_governor[DEVFREQ_NAME_LEN + 1];
>>>>>>> -    struct devfreq_governor *governor;
>>>>>>> +    const struct devfreq_governor *governor, *prev_governor;
>>>>>>>
>>>>>>>        ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
>>>>>>>        if (ret != 1)
>>>>>>> @@ -944,12 +944,21 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
>>>>>>>                goto out;
>>>>>>>            }
>>>>>>>        }
>>>>>>> +    prev_governor = df->governor;
>>>>>>>        df->governor = governor;
>>>>>>>        strncpy(df->governor_name, governor->name, DEVFREQ_NAME_LEN);
>>>>>>>        ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
>>>>>>> -    if (ret)
>>>>>>> +    if (ret) {
>>>>>>>            dev_warn(dev, "%s: Governor %s not started(%d)\n",
>>>>>>>                 __func__, df->governor->name, ret);
>>>>>>> +        if (prev_governor) {
>>>>>>
>>>>>> I think that prev_governor is always set. You don't need to check it.
>>>>>> Why do check it?
>>>>>
>>>>> Not true. Even higher up in this function, we check if df->governor != NULL. Simple example would be that the default governor passed in while adding the device isn't compiled in.
>>>>
>>>> I don't understand. If device is not registered by devfreq_add_device(),
>>>> you don't change the governor by using governor_store().
>>>>
>>>> If you can change the governor through governor_store(),
>>>> it means that the devfreq instance was added without any problem.
>>>> The added devfreq instance must have the sepecific governor
>>>> on df->governor variable.
>>>>
>>>> So, I think that df->governor is always set and then prev_governor is always set.
>>>
>>> Read the code more closely. add_device doesn't (and shouldn't) fail if the governor isn't present. After that, the governor could be changed from user space.
>>
>> If governor is not present during devfreq_add_device(),
>> the devfreq instance is not able to register the devfreq framework.
>> So, the user never touch the sysfs[1] to change the governor
>> because the sysfs[1] is not created by devfreq framework.
>> [1] /sys/class/devfreq/[device name]/governor
>>
>> In summary, if governor is not present during devfreq_add_device(),
>> the devfreq framework doesn't create tye sysfs[1] for governor.
>>
>> The user-space never change the governor through sysfs[1]
>> because there is no any sysfs entry[1].
> 
> I checked the code of devfreq_add_device().
> As you mentioned, if there is no governor,
> devfreq_add_device() don't pass wihtout calling the devfreq->governor->even_handler().

Wrong expression / don't pass -> pass

Regards,
Chanwoo Choi

> 
> I discussed this issue with Myungjoo Ham (devfreq maintainer).
> It is bug of devfreq_add_device(). I'll fix this issue.
> 
> Best Regards,
> Chanwoo Choi
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 


-- 
Best Regards,
Chanwoo Choi