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;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
