* [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start @ 2018-12-12 13:53 Sibi Sankar [not found] ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p6> 0 siblings, 1 reply; 6+ messages in thread From: Sibi Sankar @ 2018-12-12 13:53 UTC (permalink / raw) To: myungjoo.ham, kyungmin.park Cc: cw00.choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan, Sibi Sankar From: Saravana Kannan <skannan@codeaurora.org> 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: Sibi Sankar <sibis@codeaurora.org> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> --- V4: * Removed prev_governor check. V3: * Fix NULL deref for real this time. * Addressed some style preferences. V2: * Fixed typo in commit text * Fixed potential NULL deref drivers/devfreq/devfreq.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 141413067b5c..ba2875a0b90e 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -1024,7 +1024,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) @@ -1053,12 +1053,19 @@ 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); + df->governor = prev_governor; + strncpy(df->governor_name, prev_governor->name, + DEVFREQ_NAME_LEN); + df->governor->event_handler(df, DEVFREQ_GOV_START, + NULL); + } out: mutex_unlock(&devfreq_list_lock); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply related [flat|nested] 6+ messages in thread
[parent not found: <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p6>]
* RE: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start [not found] ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p6> @ 2018-12-14 1:45 ` MyungJoo Ham 2019-02-19 5:12 ` Sibi Sankar 0 siblings, 1 reply; 6+ messages in thread From: MyungJoo Ham @ 2018-12-14 1:45 UTC (permalink / raw) To: Kyungmin Park Cc: Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan, Sibi Sankar > From: Saravana Kannan <skannan@codeaurora.org> > > 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: Sibi Sankar <sibis@codeaurora.org> > Signed-off-by: Saravana Kannan <skannan@codeaurora.org> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Hello, In overall, the idea and the implementation looks good. However, I have a question: What if the following line fails? + df->governor->event_handler(df, DEVFREQ_GOV_START, + NULL); Don't we still need something to handle for such events? Cheers, MyungJoo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start 2018-12-14 1:45 ` MyungJoo Ham @ 2019-02-19 5:12 ` Sibi Sankar 2019-03-04 8:21 ` Sibi Sankar [not found] ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8> 0 siblings, 2 replies; 6+ messages in thread From: Sibi Sankar @ 2019-02-19 5:12 UTC (permalink / raw) To: myungjoo.ham, Kyungmin Park Cc: Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan Hey MyungJoo, On 12/14/18 7:15 AM, MyungJoo Ham wrote: >> From: Saravana Kannan <skannan@codeaurora.org> >> >> 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: Sibi Sankar <sibis@codeaurora.org> >> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> > > Hello, > > In overall, the idea and the implementation looks good. > > However, I have a question: > > What if the following line fails? > > + df->governor->event_handler(df, DEVFREQ_GOV_START, > + NULL); > > Don't we still need something to handle for such events? The original discussion went as follows: governor_store is expected to be used only on cases where devfreq_add_device() succeeded i.e prev->governor is expected to be present and DEVFREQ_GOV_START is expected to succeed. Hence falling back to the previous governor seems like a sensible idea. This would also prevent DEVFREQ_GOV_STOP from being called on a governor were DEVFREQ_GOV_START had failed which is ideal. That being said DEVFREQ_GOV_START can still fail for the prev-governor due to some change in state of the system. Do you want to handle this case by clearing the state of governor rather than switching to previous governor? > > Cheers, > MyungJoo > > -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start 2019-02-19 5:12 ` Sibi Sankar @ 2019-03-04 8:21 ` Sibi Sankar [not found] ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8> 1 sibling, 0 replies; 6+ messages in thread From: Sibi Sankar @ 2019-03-04 8:21 UTC (permalink / raw) To: myungjoo.ham, Kyungmin Park Cc: Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan Hey MyungJoo, Kyungmin Did you get a chance to think about how you want this fix implemented? On 2019-02-19 10:42, Sibi Sankar wrote: > Hey MyungJoo, > > On 12/14/18 7:15 AM, MyungJoo Ham wrote: >>> From: Saravana Kannan <skannan@codeaurora.org> >>> >>> 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: Sibi Sankar <sibis@codeaurora.org> >>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> >> >> Hello, >> >> In overall, the idea and the implementation looks good. >> >> However, I have a question: >> >> What if the following line fails? >> >> + df->governor->event_handler(df, DEVFREQ_GOV_START, >> + NULL); >> >> Don't we still need something to handle for such events? > > The original discussion went as follows: > governor_store is expected to be used only on cases > where devfreq_add_device() succeeded i.e prev->governor > is expected to be present and DEVFREQ_GOV_START is > expected to succeed. Hence falling back to the previous > governor seems like a sensible idea. > > This would also prevent DEVFREQ_GOV_STOP from being called > on a governor were DEVFREQ_GOV_START had failed which is > ideal. > > That being said DEVFREQ_GOV_START can still fail for the > prev-governor due to some change in state of the system. > Do you want to handle this case by clearing the state of > governor rather than switching to previous governor? > >> >> Cheers, >> MyungJoo >> >> -- -- Sibi Sankar -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8>]
* RE: Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start [not found] ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8> @ 2019-03-05 7:18 ` MyungJoo Ham 2019-03-06 17:44 ` Sibi Sankar 0 siblings, 1 reply; 6+ messages in thread From: MyungJoo Ham @ 2019-03-05 7:18 UTC (permalink / raw) To: Sibi Sankar, Kyungmin Park Cc: Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan >Hey MyungJoo, Kyungmin >Did you get a chance to think about how you >want this fix implemented? > >On 2019-02-19 10:42, Sibi Sankar wrote: >> Hey MyungJoo, >> >> On 12/14/18 7:15 AM, MyungJoo Ham wrote: >>>> From: Saravana Kannan <skannan@codeaurora.org> >>>> >>>> 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: Sibi Sankar <sibis@codeaurora.org> >>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> >>> >>> Hello, >>> >>> In overall, the idea and the implementation looks good. >>> >>> However, I have a question: >>> >>> What if the following line fails? >>> >>> + df->governor->event_handler(df, DEVFREQ_GOV_START, >>> + NULL); >>> >>> Don't we still need something to handle for such events? >> >> The original discussion went as follows: >> governor_store is expected to be used only on cases >> where devfreq_add_device() succeeded i.e prev->governor >> is expected to be present and DEVFREQ_GOV_START is >> expected to succeed. Hence falling back to the previous >> governor seems like a sensible idea. >> >> This would also prevent DEVFREQ_GOV_STOP from being called >> on a governor were DEVFREQ_GOV_START had failed which is >> ideal. >> >> That being said DEVFREQ_GOV_START can still fail for the >> prev-governor due to some change in state of the system. >> Do you want to handle this case by clearing the state of >> governor rather than switching to previous governor? >> If moving back to previous governor fails after failing for "next" governor, we may assume it's fatal and stop the device; we can simply return errors. In such a case, df->governor may need to be NULL as well. Cheers, MyungJoo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start 2019-03-05 7:18 ` MyungJoo Ham @ 2019-03-06 17:44 ` Sibi Sankar 0 siblings, 0 replies; 6+ messages in thread From: Sibi Sankar @ 2019-03-06 17:44 UTC (permalink / raw) To: myungjoo.ham Cc: Kyungmin Park, Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan, linux-kernel-owner On 2019-03-05 12:48, MyungJoo Ham wrote: >> Hey MyungJoo, Kyungmin >> Did you get a chance to think about how you >> want this fix implemented? >> >> On 2019-02-19 10:42, Sibi Sankar wrote: >>> Hey MyungJoo, >>> >>> On 12/14/18 7:15 AM, MyungJoo Ham wrote: >>>>> From: Saravana Kannan <skannan@codeaurora.org> >>>>> >>>>> 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: Sibi Sankar <sibis@codeaurora.org> >>>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> >>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> >>>> >>>> Hello, >>>> >>>> In overall, the idea and the implementation looks good. >>>> >>>> However, I have a question: >>>> >>>> What if the following line fails? >>>> >>>> + df->governor->event_handler(df, DEVFREQ_GOV_START, >>>> + NULL); >>>> >>>> Don't we still need something to handle for such events? >>> >>> The original discussion went as follows: >>> governor_store is expected to be used only on cases >>> where devfreq_add_device() succeeded i.e prev->governor >>> is expected to be present and DEVFREQ_GOV_START is >>> expected to succeed. Hence falling back to the previous >>> governor seems like a sensible idea. >>> >>> This would also prevent DEVFREQ_GOV_STOP from being called >>> on a governor were DEVFREQ_GOV_START had failed which is >>> ideal. >>> >>> That being said DEVFREQ_GOV_START can still fail for the >>> prev-governor due to some change in state of the system. >>> Do you want to handle this case by clearing the state of >>> governor rather than switching to previous governor? >>> > > If moving back to previous governor fails after > failing for "next" governor, we may assume it's fatal > and stop the device; we can simply return errors. > > In such a case, df->governor may need to be NULL as well. Thanks. Will make the necessary changes in the next re-spin. > > > Cheers, > MyungJoo -- -- Sibi Sankar -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-06 17:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-12 13:53 [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start Sibi Sankar [not found] ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p6> 2018-12-14 1:45 ` MyungJoo Ham 2019-02-19 5:12 ` Sibi Sankar 2019-03-04 8:21 ` Sibi Sankar [not found] ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8> 2019-03-05 7:18 ` MyungJoo Ham 2019-03-06 17:44 ` Sibi Sankar
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).