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
| ||
|
Date: Fri, 20 Sep 2013 10:33:22 +0200 From: Linus Walleij <linus.walleij@...aro.org> To: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com> Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Viresh Kumar <viresh.kumar@...aro.org> Subject: Re: Regression on cpufreq in v3.12-rc1 On Thu, Sep 19, 2013 at 2:55 PM, Linus Walleij <linus.walleij@...aro.org> wrote: > On Thu, Sep 19, 2013 at 2:46 PM, Srivatsa S. Bhat > <srivatsa.bhat@...ux.vnet.ibm.com> wrote: > >> So I think we should first identify (bisect?) and understand what caused that >> particular change and then we will be in a position to evaluate whether the >> patch you proposed would be the right fix or not. > > I'll see if I can get a bisect going, the problem is that I upload the > kernel over the serial port so this isn't a very quick procedure :-( Well I did a bisect anyway, it seems the problem appears due at this commit: commit 6eed9404ab3c4baea54ce4c7e862e69df1d39f38 Author: Viresh Kumar <viresh.kumar@...aro.org> Date: Tue Aug 6 22:53:11 2013 +0530 cpufreq: Use rwsem for protecting critical sections Critical sections of the cpufreq core are protected with the help of the driver module owner's refcount, which isn't the correct approach, because it causes rmmod to return an error when some routine has updated that refcount. Let's use rwsem for this purpose instead. Only cpufreq_unregister_driver() will use write sem and everybody else will use read sem. [rjw: Subject & changelog] Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com> I suspect this hunk from the patch may be the cause: + if (cpufreq_driver) { + /* get the CPU */ + policy = per_cpu(cpufreq_cpu_data, cpu); + if (policy) + kobject_get(&policy->kobj); + } - /* get the CPU */ - policy = per_cpu(cpufreq_cpu_data, cpu); As you see we *always* set a policy pointer before this patch, but after this patch we only do it if we have a cpufreq driver registered! It's not trivial to fix this for me though, it seems there are some other suggestions in this thread... Yours, Linus Walleij -- 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