At Mon, 29 May 2006 21:07:07 +0200, Ingo Molnar wrote: > > > * Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
