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

[Jan Kiszka <jan.kiszka@siemens.com>]

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