Messages in this thread | | | Date | Mon, 27 Apr 2009 10:43:28 +0200 | From | Jan Kiszka <> | 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
| |