Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932237AbWE3KeO (ORCPT ); Tue, 30 May 2006 06:34:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932238AbWE3KeO (ORCPT ); Tue, 30 May 2006 06:34:14 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51865 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S932237AbWE3KeO (ORCPT ); Tue, 30 May 2006 06:34:14 -0400 Date: Tue, 30 May 2006 12:34:12 +0200 Message-ID: From: Takashi Iwai To: Andrew Morton Cc: "Michal Piotrowski" , mingo@elte.hu, perex@suse.cz, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: 2.6.17-rc4-mm3-lockdep BUG: possible deadlock detected! In-Reply-To: <20060529114749.ba020660.akpm@osdl.org> References: <6bffcb0e0605291132u701cd69tb855cf60fa317994@mail.gmail.com> <20060529114749.ba020660.akpm@osdl.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta25) (eggplant) (+CVS-20060326) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1999 Lines: 64 At Mon, 29 May 2006 11:47:49 -0700, Andrew Morton wrote: > > On Mon, 29 May 2006 20:32:47 +0200 > "Michal Piotrowski" 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: [] > > snd_seq_port_connect+0xc0/0x337 [snd_seq] > > > > but task is already holding lock: > > (&grp->list_mutex){----}, at: [] > > 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: [] > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/