| Date | Tue, 30 May 2006 00:41:08 +0200 | From | Ingo Molnar <> | Subject | Re: [patch 00/61] ANNOUNCE: lock validator -V1 |
| |
* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 29/05/06, Ingo Molnar <mingo@elte.hu> wrote: > >We are pleased to announce the first release of the "lock dependency > >correctness validator" kernel debugging feature, which can be downloaded > >from: > > > > http://redhat.com/~mingo/lockdep-patches/ > > > [snip] > > I get this while loading cpufreq modules > > ===================================================== > [ 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?
> stack backtrace: > <c1003f36> show_trace+0xd/0xf <c1004449> dump_stack+0x17/0x19 > <c103863e> print_circular_bug_tail+0x59/0x64 <c1038e91> > __lockdep_acquire+0x848/0xa39 > <c10394be> lockdep_acquire+0x69/0x82 <c11ed759> > __mutex_lock_slowpath+0xd0/0x347
there's one small detail to improve future lockdep printouts: please set CONFIG_STACK_BACKTRACE_COLS=1, so that the backtrace is more readable. (i'll change the code to force that when CONFIG_LOCKDEP is enabled)
> BTW I still must revert lockdep-serial.patch - it doesn't compile on > my gcc 4.1.1
ok, will check this.
Ingo - 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/
|