Messages in this thread | | | Date | Tue, 30 May 2006 16:14:35 +0200 | From | Takashi Iwai <> | Subject | Re: [Alsa-devel] 2.6.17-rc4-mm3-lockdep BUG: possible deadlock detected! |
| |
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 - 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/
| |