From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga01.intel.com ([192.55.52.88]:39522 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751726AbYFXHkZ (ORCPT ); Tue, 24 Jun 2008 03:40:25 -0400 Subject: iw lockdep warning on wireless-testing From: Zhu Yi To: linux-wireless@vger.kernel.org Content-Type: text/plain Date: Tue, 24 Jun 2008 15:39:34 +0800 Message-Id: <1214293174.14590.229.camel@debian.sh.intel.com> (sfid-20080624_094030_856715_6751BF69) Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: Hi, I begin to see below lockdep warning on wireless-testing when I use iw to create a monitor interface with iwl4965. Any clues? Thanks, -yi ======================================================= [ 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. 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 other info that might help us debug this: 1 lock held by iw/2763: #0: (nlk->cb_mutex){--..}, at: [] netlink_dump +0x40/0x19d stack backtrace: Pid: 2763, comm: iw Not tainted 2.6.26-rc6-wl #57 Call Trace: [] print_circular_bug_tail+0x69/0x72 [] 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