Re: 2.6.17-rc4-mm3-lockdep BUG: possible deadlock detected!

[Ingo Molnar <mingo@elte.hu>]

* 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. 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) {