At Mon, 29 May 2006 11:47:49 -0700, Andrew Morton wrote: > > On Mon, 29 May 2006 20:32:47 +0200 > "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/ > > > > ==================================== > > [ BUG: possible deadlock detected! ] > > ------------------------------------ > > modprobe/592 is trying to acquire lock: > > (&grp->list_mutex){----}, at: [<fd9ee555>] > > snd_seq_port_connect+0xc0/0x337 [snd_seq] > > > > but task is already holding lock: > > (&grp->list_mutex){----}, at: [<fd9ee4fb>] > > snd_seq_port_connect+0x66/0x337 [snd_seq] > > > > which could potentially lead to deadlocks! > > > > other info that might help us debug this: > > 1 locks held by modprobe/592: > > #0: (&grp->list_mutex){----}, at: [<fd9ee4fb>] > > snd_seq_port_connect+0x66/0x337 [snd_seq] > > yes, > > down_write(&src->list_mutex); > down_write(&dest->list_mutex); > > I wonder if there's anything which prevents another task from concurrently > coming in and trying to perform the opposite connection and causing a > deadlock. I'm not 100% sure but I don't think the deadlock occurs because the object has actually two locks, namely, port.c_src.list_mutex port.c_dst.list_mutex so the above is equivalent with down(port_A.c_src.list_mutex); down(port_B.c_dst.list_mutex); When the opposite connection is performed concurrently, different locks are taken: down(port_B.c_src.list_mutex); down(port_A.c_dst.list_mutex); In the code, there is another place that using down_write() (in clear_subscriber_list()), but it's already after closing accesses to that port, hence there can be no race there. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
