From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga02.intel.com ([134.134.136.20]:19386 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750836AbYFXJGm (ORCPT ); Tue, 24 Jun 2008 05:06:42 -0400 Subject: Re: iw lockdep warning on wireless-testing From: Zhu Yi To: Johannes Berg Cc: linux-wireless@vger.kernel.org, Thomas Graf , netdev In-Reply-To: <1214297955.8967.258.camel@johannes.berg> References: <1214293174.14590.229.camel@debian.sh.intel.com> (sfid-20080624_094030_856715_6751BF69) <1214297955.8967.258.camel@johannes.berg> Content-Type: text/plain Date: Tue, 24 Jun 2008 17:05:50 +0800 Message-Id: <1214298350.14590.238.camel@debian.sh.intel.com> (sfid-20080624_110645_985574_059A2DAD) Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Tue, 2008-06-24 at 10:59 +0200, Johannes Berg wrote: > > [ INFO: possible circular locking dependency detected ] > > 2.6.26-rc6-wl #57 > > ------------------------------------------------------- > > iw/2763 is trying to acquire lock: > > (genl_mutex){--..}, at: [] ctrl_dumpfamily > +0x31/0xf7 > > > > but task is already holding lock: > > (nlk->cb_mutex){--..}, at: [] netlink_dump > +0x40/0x19d > > > > which lock already depends on the new lock. > > None of those is anything nl80211 has influence over, afaict. Agreed. I can follow the two scenarios below. Apparently it's a ABBA locking issue. Just don't know which should be the correct sequence for using with the two locks. Thanks, -yi > > the existing dependency chain (in reverse order) is: > > > > -> #1 (nlk->cb_mutex){--..}: > > [] __lock_acquire+0xa4c/0xc28 > > [] netlink_dump_start+0xd9/0x169 > > [] lock_acquire+0x51/0x6c > > [] netlink_dump_start+0xd9/0x169 > > [] debug_mutex_lock_common+0x16/0x23 > > [] mutex_lock_nested+0xde/0x23f > > [] netlink_dump_start+0xd9/0x169 > > [] genl_rcv_msg+0xae/0x14b > > [] mutex_lock_nested+0x230/0x23f > > [] genl_rcv_msg+0x0/0x14b > > [] netlink_rcv_skb+0x34/0x7c > > [] genl_rcv+0x21/0x30 > > [] netlink_unicast+0x1f7/0x287 > > [] __alloc_skb+0x84/0x132 > > [] netlink_sendmsg+0x274/0x287 > > [] sock_sendmsg+0xe2/0xff > > [] autoremove_wake_function+0x0/0x2e > > [] mark_held_locks+0x49/0x67 > > [] sys_sendmsg+0x217/0x28a > > [] __do_fault+0x35d/0x3a5 > > [] tracesys+0xd5/0xda > > [] 0xffffffffffffffff > > > > -> #0 (genl_mutex){--..}: > > [] print_circular_bug_header+0xc8/0xcf > > [] __lock_acquire+0x951/0xc28 > > [] ctrl_dumpfamily+0x31/0xf7 > > [] lock_acquire+0x51/0x6c > > [] ctrl_dumpfamily+0x31/0xf7 > > [] debug_mutex_lock_common+0x16/0x23 > > [] mutex_lock_nested+0xde/0x23f > > [] trace_hardirqs_on+0xf3/0x117 > > [] ctrl_dumpfamily+0x31/0xf7 > > [] netlink_dump+0x5b/0x19d > > [] netlink_recvmsg+0x180/0x2a8 > > [] sock_recvmsg+0xf0/0x10f > > [] autoremove_wake_function+0x0/0x2e > > [] mark_held_locks+0x49/0x67 > > [] sys_recvmsg+0x15c/0x254 > > [] audit_syscall_entry+0x12d/0x160 > > [] trace_hardirqs_on_thunk+0x35/0x3a > > [] tracesys+0xd5/0xda > > [] 0xffffffffffffffff