From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from fmailhost01.isp.att.net ([207.115.11.51]:38296 "EHLO fmailhost01.isp.att.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752465AbZCQQQx (ORCPT ); Tue, 17 Mar 2009 12:16:53 -0400 Message-ID: <49BFCCC5.9080500@lwfinger.net> (sfid-20090317_171658_112665_EE683184) Date: Tue, 17 Mar 2009 11:16:05 -0500 From: Larry Finger MIME-Version: 1.0 To: Johannes Berg , Jouni Malinen CC: wireless Subject: Possible circular locking problem Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: While testing usage of b43legacy as an AP, I got the following in my logs. My kernel is the latest wireless-testing that was pulled about 2 hours ago - hostapd is 0.6.8. Larry ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.29-rc8-wl #89 ------------------------------------------------------- hostapd/6686 is trying to acquire lock: (rtnl_mutex){--..}, at: [] rtnl_lock+0x12/0x14 but task is already holding lock: (&drv->mtx){--..}, at: [] cfg80211_get_dev_from_info+0x101/0x115 [cfg80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&drv->mtx){--..}: [] __lock_acquire+0x12b4/0x161e [] lock_acquire+0x55/0x71 [] mutex_lock_nested+0x111/0x2ae [] cfg80211_get_dev_from_ifindex+0x65/0x8a [cfg80211] [] cfg80211_wext_giwscan+0x40/0xe8a [cfg80211] [] ioctl_standard_iw_point+0x16d/0x1fc [] ioctl_standard_call+0x95/0xb4 [] wext_ioctl_dispatch+0x9a/0x172 [] wext_handle_ioctl+0x39/0x6f [] dev_ioctl+0x611/0x63a [] sock_ioctl+0x20e/0x21d [] vfs_ioctl+0x2a/0x78 [] do_vfs_ioctl+0x46b/0x4ab [] sys_ioctl+0x42/0x65 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff -> #1 (cfg80211_mutex){--..}: [] __lock_acquire+0x12b4/0x161e [] lock_acquire+0x55/0x71 [] mutex_lock_nested+0x111/0x2ae [] cfg80211_get_dev_from_ifindex+0x17/0x8a [cfg80211] [] cfg80211_wext_giwscan+0x40/0xe8a [cfg80211] [] ioctl_standard_iw_point+0x16d/0x1fc [] ioctl_standard_call+0x95/0xb4 [] wext_ioctl_dispatch+0x9a/0x172 [] wext_handle_ioctl+0x39/0x6f [] dev_ioctl+0x611/0x63a [] sock_ioctl+0x20e/0x21d [] vfs_ioctl+0x2a/0x78 [] do_vfs_ioctl+0x46b/0x4ab [] sys_ioctl+0x42/0x65 [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff -> #0 (rtnl_mutex){--..}: [] __lock_acquire+0xf83/0x161e [] lock_acquire+0x55/0x71 [] mutex_lock_nested+0x111/0x2ae [] rtnl_lock+0x12/0x14 [] nl80211_new_interface+0xb8/0x18d [cfg80211] [] genl_rcv_msg+0x19a/0x1bb [] netlink_rcv_skb+0x3e/0x90 [] genl_rcv+0x29/0x39 [] netlink_unicast+0x1fe/0x274 [] netlink_sendmsg+0x27d/0x290 [] sock_sendmsg+0xdf/0xf8 [] sys_sendmsg+0x1d2/0x23c [] system_call_fastpath+0x16/0x1b [] 0xffffffffffffffff other info that might help us debug this: 2 locks held by hostapd/6686: #0: (genl_mutex){--..}, at: [] genl_rcv+0x1a/0x39 #1: (&drv->mtx){--..}, at: [] cfg80211_get_dev_from_info+0x101/0x115 [cfg80211] stack backtrace: Pid: 6686, comm: hostapd Not tainted 2.6.29-rc8-wl #89 Call Trace: [] print_circular_bug_tail+0xc5/0xd0 [] __lock_acquire+0xf83/0x161e [] ? cfg80211_get_dev_from_info+0x101/0x115 [cfg80211] [] lock_acquire+0x55/0x71 [] ? rtnl_lock+0x12/0x14 [] mutex_lock_nested+0x111/0x2ae [] ? rtnl_lock+0x12/0x14 [] ? rtnl_lock+0x12/0x14 [] rtnl_lock+0x12/0x14 [] nl80211_new_interface+0xb8/0x18d [cfg80211] [] ? validate_nla+0x96/0x141 [] genl_rcv_msg+0x19a/0x1bb [] ? genl_rcv_msg+0x0/0x1bb [] netlink_rcv_skb+0x3e/0x90 [] genl_rcv+0x29/0x39 [] ? netlink_unicast+0xfc/0x274 [] netlink_unicast+0x1fe/0x274 [] ? __alloc_skb+0x6f/0x131 [] netlink_sendmsg+0x27d/0x290 [] sock_sendmsg+0xdf/0xf8 [] ? autoremove_wake_function+0x0/0x38 [] ? _spin_unlock_irqrestore+0x3f/0x47 [] ? move_addr_to_kernel+0x40/0x49 [] ? verify_iovec+0x4f/0x91 [] sys_sendmsg+0x1d2/0x23c [] ? __d_free+0x55/0x59 [] ? d_free+0x32/0x4c [] ? mntput_no_expire+0x2a/0x13d [] ? __fput+0x19c/0x1a9 [] ? trace_hardirqs_on_caller+0x114/0x138 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] ? __up_read+0x1c/0x9a [] system_call_fastpath+0x16/0x1b