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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Mon, 29 May 2006 21:07:07 +0200,
Ingo Molnar wrote:
> 
> 
> * Michal Piotrowski <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux