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: <CAGTfZH0bDUBabPEZTGgD2U2YGAWkgKkGbsa4gVTdh=bq23Sn=Q@mail.gmail.com>
Date:   Sat, 12 Nov 2016 11:18:51 +0900
From:   Chanwoo Choi <cwchoi00@...il.com>
To:     Saravana Kannan <skannan@...eaurora.org>
Cc:     Chanwoo Choi <cw00.choi@...sung.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] PM / devfreq: Restart previous governor if new
 governor fails to start

2016-11-12 11:17 GMT+09:00 Chanwoo Choi <cwchoi00@...il.com>:
> 2016-11-12 8:25 GMT+09:00 Saravana Kannan <skannan@...eaurora.org>:
>> On 11/09/2016 04:10 PM, Chanwoo Choi wrote:
>>>
>>> Hi,
>>>
>>> On 2016년 11월 10일 05:34, Saravana Kannan wrote:
>>>>
>>>> On 11/08/2016 06:38 PM, Chanwoo Choi wrote:
>>>>>
>>>>> 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
>>>>>
>>>>
>>>> I think it's correct as is. Just because the governor isn't there (or
>>>> hasn't registered yet) doesn't mean the device add should fail.
>>>>
>>>> That aside, do you care to ack this patch for the way the code is
>>>> currently?
>>>
>>>
>>> Reviewed-by: Chanwoo Choi <cw00.choi@...sung.com>
>>
>>
>> Thanks
>>
>>> After fixing the bug of devfreq_add_device(),
>>> I'll remove the unneeded 'if statement' of prev_governor in
>>> governor_store.
>>>
>>
>> As mentioned earlier, I don't think it's a bug. It's fine as is.
>
> No. I think it is a bug. The goal of devfreq should handle the frequency/voltage
> with governor. If governor is not necessary of the specific device, the device
> driver don't need to use the devfreq.
>
> The default governor is always available and necessary of the device driver.

The default governor have to be always available and necessary of the
device driver.


-- 
Best Regards,
Chanwoo Choi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ