From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750927AbWE3OOi (ORCPT ); Tue, 30 May 2006 10:14:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750940AbWE3OOi (ORCPT ); Tue, 30 May 2006 10:14:38 -0400 Received: from cantor2.suse.de ([195.135.220.15]:41911 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1750871AbWE3OOh (ORCPT ); Tue, 30 May 2006 10:14:37 -0400 Date: Tue, 30 May 2006 16:14:35 +0200 Message-ID: From: Takashi Iwai To: Ingo Molnar Cc: Michal Piotrowski , Andrew Morton , alsa-devel@alsa-project.org, LKML , perex@suse.cz Subject: Re: [Alsa-devel] 2.6.17-rc4-mm3-lockdep BUG: possible deadlock detected! In-Reply-To: <20060529190707.GB24445@elte.hu> References: <6bffcb0e0605291132u701cd69tb855cf60fa317994@mail.gmail.com> <20060529190707.GB24445@elte.hu> 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 At Mon, 29 May 2006 21:07:07 +0200, Ingo Molnar wrote: > > > * Michal Piotrowski 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. As mentioned in another post, different locks are used depending whether it's source or destination. Thus the confliction doesn't occur in the reverse order. > 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? Yes, exactly. read_lock(grp->list_lock) is used in seq_clientmgr.c for the atomic contexts to follow the linked list. Takashi