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
| ||
|
Message-ID: <3158268.Ad2sxChQ89@vostro.rjw.lan> Date: Thu, 19 Jun 2014 01:57:54 +0200 From: "Rafael J. Wysocki" <rjw@...ysocki.net> To: Aaron Plattner <aplattner@...dia.com> Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, Viresh Kumar <viresh.kumar@...aro.org>, "Rafael J. Wysocki" <rafael.j.wysocki@...el.com> Subject: Re: [PATCH v2] cpufreq: unlock when failing cpufreq_update_policy() On Wednesday, June 18, 2014 11:27:32 AM Aaron Plattner wrote: > Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if > cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy' > label, which exits without unlocking any of the locks the function acquired > earlier. This causes later calls into cpufreq to hang. > > Fix this by creating a new 'unlock' label and jumping to that instead. > > v2: Delete the no_policy label and just return early if policy is NULL. > > Fixes: bd0fa9bb455d ("cpufreq: Return error if ->get() failed in cpufreq_update_policy()") > Link: https://devtalk.nvidia.com/default/topic/751903/kernel-3-15-and-nv-drivers-337-340-failed-to-initialize-the-nvidia-kernel-module-gtx-550-ti-/ > Cc: Viresh Kumar <viresh.kumar@...aro.org> > Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com> > Signed-off-by: Aaron Plattner <aplattner@...dia.com> Applied, thanks! > --- > v1 of this was tested by the user affected by the problem, but I don't have his > email address so I can't add it as a Tested-by line. > > drivers/cpufreq/cpufreq.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index aed2b0cb83dc..62259d27f03e 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2242,10 +2242,8 @@ int cpufreq_update_policy(unsigned int cpu) > struct cpufreq_policy new_policy; > int ret; > > - if (!policy) { > - ret = -ENODEV; > - goto no_policy; > - } > + if (!policy) > + return -ENODEV; > > down_write(&policy->rwsem); > > @@ -2264,7 +2262,7 @@ int cpufreq_update_policy(unsigned int cpu) > new_policy.cur = cpufreq_driver->get(cpu); > if (WARN_ON(!new_policy.cur)) { > ret = -EIO; > - goto no_policy; > + goto unlock; > } > > if (!policy->cur) { > @@ -2279,10 +2277,10 @@ int cpufreq_update_policy(unsigned int cpu) > > ret = cpufreq_set_policy(policy, &new_policy); > > +unlock: > up_write(&policy->rwsem); > > cpufreq_cpu_put(policy); > -no_policy: > return ret; > } > EXPORT_SYMBOL(cpufreq_update_policy); > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists