Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933932AbWKTJIS (ORCPT ); Mon, 20 Nov 2006 04:08:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S934015AbWKTJIS (ORCPT ); Mon, 20 Nov 2006 04:08:18 -0500 Received: from amsfep17-int.chello.nl ([213.46.243.15]:49563 "EHLO amsfep16-int.chello.nl") by vger.kernel.org with ESMTP id S933932AbWKTJIQ (ORCPT ); Mon, 20 Nov 2006 04:08:16 -0500 Subject: Re: 2.6.19-rc5: lockdep warnings starting irattach From: Peter Zijlstra To: Andrey Borzenkov , Andrew Morton Cc: samuel@sortiz.org, irda-users@lists.sourceforge.net, linux-kernel@vger.kernel.org, Ingo Molnar , arjan In-Reply-To: <200611181612.36008.arvidjaar@mail.ru> References: <200611181612.36008.arvidjaar@mail.ru> Content-Type: text/plain Date: Mon, 20 Nov 2006 10:04:46 +0100 Message-Id: <1164013486.5968.133.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3021 Lines: 80 On Sat, 2006-11-18 at 16:12 +0300, Andrey Borzenkov wrote: > ============================================= > [ INFO: possible recursive locking detected ] > 2.6.19-rc5-2avb #2 > - --------------------------------------------- > pppd/26425 is trying to acquire lock: > (&hashbin->hb_spinlock){....}, at: [] irlmp_slsap_inuse+0x5a/0x170 > [irda] > > but task is already holding lock: > (&hashbin->hb_spinlock){....}, at: [] irlmp_slsap_inuse+0x37/0x170 > [irda] > > other info that might help us debug this: > 1 lock held by pppd/26425: > #0: (&hashbin->hb_spinlock){....}, at: [] > irlmp_slsap_inuse+0x37/0x170 [irda] > > stack backtrace: > [] dump_trace+0x1cc/0x200 > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x20 > [] dump_stack+0x19/0x20 > [] __lock_acquire+0x8fa/0xc20 > [] lock_acquire+0x5d/0x80 > [] _spin_lock+0x2c/0x40 > [] irlmp_slsap_inuse+0x5a/0x170 [irda] > [] irlmp_open_lsap+0x62/0x180 [irda] > [] irttp_open_tsap+0x181/0x230 [irda] > [] ircomm_open_tsap+0x5d/0xa0 [ircomm] > [] ircomm_open+0xb8/0xd0 [ircomm] > [] ircomm_tty_open+0x4f7/0x570 [ircomm_tty] > [] tty_open+0x174/0x340 > [] chrdev_open+0x89/0x170 > [] __dentry_open+0xa6/0x1d0 > [] nameidata_to_filp+0x35/0x40 > [] do_filp_open+0x49/0x50 > [] do_sys_open+0x47/0xd0 > [] sys_open+0x1c/0x20 > [] sysenter_past_esp+0x56/0x8d > [] 0xb7f86410 > ======================= The comment at the nesting lock says: /* Careful for priority inversions here ! * irlmp->links is never taken while another IrDA * spinlock is held, so we are safe. Jean II */ So, under the assumption the author was right, it just needs a lockdep annotation. (depends on patches in -mm for spin_lock_irqsave_nested()) Signed-off-by: Peter Zijlstra --- net/irda/irlmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-mm/net/irda/irlmp.c =================================================================== --- linux-2.6-mm.orig/net/irda/irlmp.c 2006-11-20 09:54:50.000000000 +0100 +++ linux-2.6-mm/net/irda/irlmp.c 2006-11-20 09:57:39.000000000 +0100 @@ -1678,7 +1678,7 @@ static int irlmp_slsap_inuse(__u8 slsap_ * every IrLAP connection and check every LSAP associated with each * the connection. */ - spin_lock_irqsave(&irlmp->links->hb_spinlock, flags); + spin_lock_irqsave_nested(&irlmp->links->hb_spinlock, flags, 1); lap = (struct lap_cb *) hashbin_get_first(irlmp->links); while (lap != NULL) { IRDA_ASSERT(lap->magic == LMP_LAP_MAGIC, goto errlap;); - 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/