On 09/20, Viresh Kumar wrote: > 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.
s/Lets/Let's/ > > Reported-by: Chanwoo Choi <cw00.c...@samsung.com> > Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> > --- > drivers/base/power/opp/core.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > 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? That would be the only difference from before. It's possible that nobody cares about this situation though. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
