Messages in this thread | | | Date | Mon, 29 May 2006 19:09:08 -0400 | From | Dave Jones <> | Subject | Re: [patch 00/61] ANNOUNCE: lock validator -V1 |
| |
On Tue, May 30, 2006 at 12:41:08AM +0200, Ingo Molnar wrote:
> > ===================================================== > > [ BUG: possible circular locking deadlock detected! ] > > ----------------------------------------------------- > > modprobe/1942 is trying to acquire lock: > > (&anon_vma->lock){--..}, at: [<c10609cf>] anon_vma_link+0x1d/0xc9 > > > > but task is already holding lock: > > (&mm->mmap_sem/1){--..}, at: [<c101e5a0>] copy_process+0xbc6/0x1519 > > > > which lock already depends on the new lock, > > which could lead to circular deadlocks! > > hm, this one could perhaps be a real bug. Dave: lockdep complains about > having observed: > > anon_vma->lock => mm->mmap_sem > mm->mmap_sem => anon_vma->lock > > locking sequences, in the cpufreq code. Is there some special runtime > behavior that still makes this safe, or is it a real bug?
I'm feeling a bit overwhelmed by the voluminous output of this checker. Especially as (directly at least) cpufreq doesn't touch vma's, or mmap's.
The first stack trace it shows has us down in the bowels of cpu hotplug, where we're taking the cpucontrol sem. The second stack trace shows us in cpufreq_update_policy taking a per-cpu data->lock semaphore.
Now, I notice this is modprobe triggering this, and this *looks* like we're loading two modules simultaneously (the first trace is from a scaling driver like powernow-k8 or the like, whilst the second trace is from cpufreq-stats).
How on earth did we get into this situation? module loading is supposed to be serialised on the module_mutex no ?
It's been a while since a debug patch has sent me in search of paracetamol ;)
Dave
-- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |