| Message ID | 45c7e892a69c4936993c65c9987981dbe4433148.1505920911.git.viresh.kumar@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | PM / OPP: Call notifier without holding opp_table->lock | expand |
On 20-09-17, 10:00, Stephen Boyd wrote: > On 09/20, Viresh Kumar wrote: > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c > > index 4360b4efcd4c..668fd940d362 100644 > > --- a/drivers/base/power/opp/core.c > > +++ b/drivers/base/power/opp/core.c > > @@ -1627,6 +1627,9 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, > > > > opp->available = availability_req; > > > > + dev_pm_opp_get(opp); > > + mutex_unlock(&opp_table->lock); > > Does this prevent the OPP from changing while the lock is > released? No, its just ref counting and will only prevent it from getting freed. There is only one thing that can change for an OPP though after it is created, its availability. > That would be the only difference from before. It's > possible that nobody cares about this situation though. I am not sure if its worth caring for right now :) Also the notifier chain will not start again until the previous call chain is finished. So we are kind of synchronized here. -- viresh
diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c index 4360b4efcd4c..668fd940d362 100644 --- a/drivers/base/power/opp/core.c +++ b/drivers/base/power/opp/core.c @@ -1627,6 +1627,9 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, opp->available = availability_req; + dev_pm_opp_get(opp); + mutex_unlock(&opp_table->lock); + /* Notify the change of the OPP availability */ if (availability_req) blocking_notifier_call_chain(&opp_table->head, OPP_EVENT_ENABLE, @@ -1635,8 +1638,12 @@ static int _opp_set_availability(struct device *dev, unsigned long freq, blocking_notifier_call_chain(&opp_table->head, OPP_EVENT_DISABLE, opp); + dev_pm_opp_put(opp); + goto put_table; + unlock: mutex_unlock(&opp_table->lock); +put_table: dev_pm_opp_put_opp_table(opp_table); return r; }
The notifier callbacks may want to call some OPP helper routines which may try to take the same opp_table->lock again and cause a deadlock. One such usecase was reported by Chanwoo Choi, where calling dev_pm_opp_disable() leads us to the devfreq's OPP notifier handler, which further calls dev_pm_opp_find_freq_floor() and it deadlocks. We don't really need the opp_table->lock to be held across the notifier call though, all we want to make sure is that the 'opp' doesn't get freed while being used from within the notifier chain. We can do it with help of dev_pm_opp_get/put() as well. Lets do it. Reported-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- drivers/base/power/opp/core.c | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.7.4