linux-kernel - Re: Regression on cpufreq in v3.12-rc1

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKohpok_u=yUsw3pci90G0sKYy2Ndg8qc9SW+wJm_woSfQhy-g@mail.gmail.com>
Date:	Thu, 19 Sep 2013 19:42:03 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Regression on cpufreq in v3.12-rc1

On 19 September 2013 18:28, Srivatsa S. Bhat
<srivatsa.bhat@...ux.vnet.ibm.com> wrote:
> On 09/19/2013 06:25 PM, Linus Walleij wrote:

>> The problem is not what it returns, the system seems to survive no matter
>> whether it returns 0 or 17 or whatever.
>>
>
> Of course. What I intended to say was that I don't recall recent kernels
> returning _anything_ on !policy. So there wasn't any sudden change in _that_
> piece of code, AFAIR.
>
>> The problem is that sometimes in the v3.12 kernel cycle we got a
>> BUG() crash instead of some random value back for calling early.
>>
>
> Yep, and that's most likely due to some change in ordering of calls somewhere,
> which makes calls to lock_policy_rwsem_read() before it is safe to do so,
> rather than anything related to how lock_policy_rwsem_read() handles the call.

I don't see any problem in the order things are called from both the places
where you got the crash from.. Because cpufreq driver is registered with
arch_initcall() and both the crash locations gets initialized after that..

I believe the problem is, cpufreq driver failed to register for some reason
and so we are getting this problem...

Can you please confirm if cpufreq driver failed to register or not?

And, I have another solution in mind for getting this problem fixed,
will get that to you by then..
--
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/