* 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. 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? Ingo Index: linux/sound/core/seq/seq_ports.c =================================================================== --- linux.orig/sound/core/seq/seq_ports.c +++ linux/sound/core/seq/seq_ports.c @@ -518,7 +518,7 @@ int snd_seq_port_connect(struct snd_seq_ atomic_set(&subs->ref_count, 2); down_write(&src->list_mutex); - down_write(&dest->list_mutex); + down_write_nested(&dest->list_mutex, SINGLE_DEPTH_NESTING); exclusive = info->flags & SNDRV_SEQ_PORT_SUBS_EXCLUSIVE ? 1 : 0; err = -EBUSY; @@ -591,7 +591,7 @@ int snd_seq_port_disconnect(struct snd_s unsigned long flags; down_write(&src->list_mutex); - down_write(&dest->list_mutex); + down_write_nested(&dest->list_mutex, SINGLE_DEPTH_NESTING); /* look for the connection */ list_for_each(p, &src->list_head) { _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
