On 29 August 2013 14:07, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 28 August 2013 22:22, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: >> On 08/27/13 23:58, Viresh Kumar wrote: >>> I haven't gone through the hack yet, but I am trying to understand the >>> problem first.. There had been some work in the past around this >>> kind of scenarios.. >>> >>> commit 95731ebb114c5f0c028459388560fc2a72fe5049 >>> Author: Xiaoguang Chen <chenxg@xxxxxxxxxxx> >>> Date: Wed Jun 19 15:00:07 2013 +0800 >>> >>> cpufreq: Fix governor start/stop race condition >>> >>> >>> The problem probably is poor error checking which is still present at >>> few places, in __cpufreq_set_policy() routine.. >>> >>> Can you try after fixing them? Something similar has to be done.. >>> >>> commit 3de9bdeb28638e164d1f0eb38dd68e3f5d2ac95c >>> Author: Viresh Kumar <viresh.kumar@xxxxxxxxxx> >>> Date: Tue Aug 6 22:53:13 2013 +0530 >>> >>> cpufreq: improve error checking on return values of __cpufreq_governor() >> >> No the problem isn't poor error checking. The problem is between >> gov_stop and gov_start userspace can come in and write scaling_min_freq >> which will try to acquire the mutex (sorry the copy paste of the error >> got messed up so I've repasted it). I forgot to answer here :( I would still say this could be a problem.. Suppose one thread tried to STOP governor and stopped it.. Now other one came and tried to STOP it, it failed but due to poor error checking, went ahead to next step.. and then they got into issues.. I still see this as an potential issue in this case.. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
