linux-kernel - Re: [BUG -tip] unable to handle kernel paging request

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 for Android: free password hash cracker in your pocket

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

Message-ID: <49F57030.3010802@siemens.com>
Date:	Mon, 27 Apr 2009 10:43:28 +0200
From:	Jan Kiszka <jan.kiszka@...mens.com>
To:	Luis Henriques <henrix@...o.pt>
CC:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Dave Jones <davej@...hat.com>, Ingo Molnar <mingo@...hat.com>,
	mark.langsdorf@....com, linux-kernel@...r.kernel.org,
	Avi Kivity <avi@...hat.com>
Subject: Re: [BUG -tip] unable to handle kernel paging request

Luis Henriques wrote:
> (CC'ing Avi Kivity and Jan Kiszka)
> On Mon, Apr 13, 2009 at 01:59:08PM -0700, Paul E. McKenney wrote:
>> On Mon, Apr 13, 2009 at 05:59:13PM +0100, Luis Henriques wrote:
>>> Hi,
>>>
>>> (not sure if I'm CC'ing all the relevant persons...)
>>>
>>> I am hitting this bug, which occurs mainly when I am shutting down my laptop.  I
>>> took a look at the cpufreq code and found out something which I am not sure if it
>>> is related with this bug (or even if it is an issue at all):
>>>
>>> void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state)
>>> {
>>>         struct cpufreq_policy *policy;
>>>
>>>         BUG_ON(irqs_disabled());
>>>
>>>         freqs->flags = cpufreq_driver->flags;
>>>
>>> 		...
>>>
>>> This code accesses cpufreq_driver without using the cpufreq_driver_lock.  I
>>> believe this is the only place in the code where this lock is not obtaining
>>> before accessing the global cpufreq_driver.
>>>
>>> Any ideas?
>> Well, one thought would be that SRCU is protecting it, but when I look
>> at the code, SRCU is instead only protecting the notifier chain itself.
>> So SRCU is -not- a substitute for cpufreq_driver_lock in this case.
>>
>> But the "freqs" argument looks to be a parameter block private to the
>> caller, so the modification of freqs->old is safe.  Ditto for
>> adjust_jiffies().
>>
>> This does use per-CPU data, but it is not clear to me how preemption is
>> disabled -- or that it is always operating on the current CPU, for that
>> matter.  And the few notifier callbacks I looked at did not have any
>> locking either.
>>
>> So is the cpufreq_driver_lock acquired at a higher level, for example,
>> by the guy who calls through the cpufreq_driver control blocks?
>>
>> 							Thanx, Paul
> 
> I believe my problem has finally been solved by commit
> 888d256e9c565cb61505bd218eb37c81fe77a325 in kvm git tree.  Basically, the kvm
> notifier for the cpufreq was not being unregistered when kvm module was
> unloaded and, thus, when notifier_call_chain invoked the handler for the kvm,
> there was a NULL pointer there.
> 
> Does this make sense to everybody?

If your system unloads the kvm modules on shutdown/reboot: yes, would
make sense.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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/