Re: [Alsa-devel] 2.6.17-rc4-mm3-lockdep BUG: possible deadlock detected!

[Takashi Iwai <tiwai@suse.de>]

At Mon, 29 May 2006 21:07:07 +0200,
Ingo Molnar wrote:
> 
> 
> * Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> 
> > I get this with Ingo's lockdep patch from
> > http://people.redhat.com/mingo/generic-irq-subsystem/
> 
> sigh, that patchset is not released yet ... it showed up in the genirq 
> directory accidentally. (will release it later today)
> 
> > ====================================
> > [ BUG: possible deadlock detected! ]
> > ------------------------------------
> 
> at first sight this looks like a rare case of nested locking not yet 
> covered by the lock validator. Could you try the patch below, to 
> correctly express this locking construct to the lock validator?
> 
> Btw., beyond this false positive, i dont see how the lock ordering 
> between ports is guaranteed - maybe there's some implicit rule that 
> enforces it.

As mentioned in another post, different locks are used depending
whether it's source or destination.  Thus the confliction doesn't
occur in the reverse order.

>  And the whole grp->list_lock and grp->list_mutex lock use 
> seems quite fragile - using list_lock in atomic contexts and list_mutex 
> in schedulable contexts?

Yes, exactly.  read_lock(grp->list_lock) is used in seq_clientmgr.c
for the atomic contexts to follow the linked list.


Takashi