Re: [patch 00/61] ANNOUNCE: lock validator -V1

[Dave Jones <davej@redhat.com>]

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/