2.6.21-rc3 snd-usb-audio lockdep report.

2.6.21-rc3 snd-usb-audio lockdep report.

[Dave Jones]

=============================================
[ INFO: possible recursive locking detected ]
2.6.20-1.2962.fc7 #1
---------------------------------------------
rosegardenseque/5229 is trying to acquire lock:
 (&grp->list_mutex){----}, at: [<ffffffff881d4352>] snd_seq_deliver_event+0x93/0x173 [snd_seq]

but task is already holding lock:
 (&grp->list_mutex){----}, at: [<ffffffff881d4352>] snd_seq_deliver_event+0x93/0x173 [snd_seq]

other info that might help us debug this:
1 lock held by rosegardenseque/5229:
 #0:  (&grp->list_mutex){----}, at: [<ffffffff881d4352>] snd_seq_deliver_event+0x93/0x173 [snd_seq]

stack backtrace:

Call Trace:
 [<ffffffff802a303b>] __lock_acquire+0x151/0xbc4
 [<ffffffff802a3ea4>] lock_acquire+0x4c/0x65
 [<ffffffff881d4352>] :snd_seq:snd_seq_deliver_event+0x93/0x173
 [<ffffffff8029eab8>] down_read+0x3e/0x4a
 [<ffffffff881d4352>] :snd_seq:snd_seq_deliver_event+0x93/0x173
 [<ffffffff881d56c6>] :snd_seq:snd_seq_kernel_client_dispatch+0x54/0x68
 [<ffffffff881fd05f>] :snd_seq_dummy:dummy_input+0x54/0x5a
 [<ffffffff881d41cb>] :snd_seq:snd_seq_deliver_single_event+0xf8/0x1ec
 [<ffffffff881d43a1>] :snd_seq:snd_seq_deliver_event+0xe2/0x173
 [<ffffffff881d4819>] :snd_seq:snd_seq_dispatch_event+0xed/0x110
 [<ffffffff881d6e0e>] :snd_seq:snd_seq_check_queue+0xbc/0x105
 [<ffffffff881d70e3>] :snd_seq:snd_seq_enqueue_event+0xb6/0xca
 [<ffffffff881d4501>] :snd_seq:snd_seq_client_enqueue_event+0xcf/0x101
 [<ffffffff881d5db2>] :snd_seq:snd_seq_write+0x140/0x198
 [<ffffffff8021634f>] vfs_write+0xcf/0x178
 [<ffffffff80216d64>] sys_write+0x47/0x70
 [<ffffffff8025c2b5>] tracesys+0xdc/0xe1


-- 
http://www.codemonkey.org.uk

Re: 2.6.21-rc3 snd-usb-audio lockdep report.

[Takashi Iwai]

At Sat, 10 Mar 2007 00:31:33 -0500,
Dave Jones wrote:
> 
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.20-1.2962.fc7 #1
> ---------------------------------------------
> rosegardenseque/5229 is trying to acquire lock:
>  (&grp->list_mutex){----}, at: [<ffffffff881d4352>] snd_seq_deliver_event+0x93/0x173 [snd_seq]
> 
> but task is already holding lock:
>  (&grp->list_mutex){----}, at: [<ffffffff881d4352>] snd_seq_deliver_event+0x93/0x173 [snd_seq]
> 
> other info that might help us debug this:
> 1 lock held by rosegardenseque/5229:
>  #0:  (&grp->list_mutex){----}, at: [<ffffffff881d4352>] snd_seq_deliver_event+0x93/0x173 [snd_seq]

Hm, these are read-only so they should never conflict.
Is there a better workaround than *_non_owner()?


Takashi

diff -r a8aa25c670eb sound/core/seq/seq_clientmgr.c
--- a/sound/core/seq/seq_clientmgr.c	Mon Mar 12 11:39:01 2007 +0100
+++ b/sound/core/seq/seq_clientmgr.c	Mon Mar 12 12:12:44 2007 +0100
@@ -672,7 +672,7 @@ static int deliver_to_subscribers(struct
 	if (atomic)
 		read_lock(&grp->list_lock);
 	else
-		down_read(&grp->list_mutex);
+		down_read_non_owner(&grp->list_mutex);
 	list_for_each_entry(subs, &grp->list_head, src_list) {
 		event->dest = subs->info.dest;
 		if (subs->info.flags & SNDRV_SEQ_PORT_SUBS_TIMESTAMP)
@@ -690,7 +690,7 @@ static int deliver_to_subscribers(struct
 	if (atomic)
 		read_unlock(&grp->list_lock);
 	else
-		up_read(&grp->list_mutex);
+		up_read_non_owner(&grp->list_mutex);
 	*event = event_saved; /* restore */
 	snd_seq_port_unlock(src_port);
 	return (err < 0) ? err : num_ev;