From patchwork Sat Sep 17 10:23:18 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ferenc Wagner X-Patchwork-Id: 115121 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id B8A84B6F7E for ; Sat, 17 Sep 2011 20:59:22 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751553Ab1IQK7L (ORCPT ); Sat, 17 Sep 2011 06:59:11 -0400 Received: from tac.ki.iif.hu ([193.6.222.43]:41091 "EHLO tac.ki.iif.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751204Ab1IQK7K (ORCPT ); Sat, 17 Sep 2011 06:59:10 -0400 X-Greylist: delayed 2121 seconds by postgrey-1.27 at vger.kernel.org; Sat, 17 Sep 2011 06:59:10 EDT Received: from wferi by tac.ki.iif.hu with local (Exim 4.72) (envelope-from ) id 1R4s3K-0000NY-BC; Sat, 17 Sep 2011 12:23:18 +0200 From: Ferenc Wagner To: Stanislaw Gruszka Cc: Johannes Berg , "David S. Miller" , "John W. Linville" , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: mac80211 regression (deadlock) with built-in ipw2200 Date: Sat, 17 Sep 2011 12:23:18 +0200 Message-ID: <877h57jwmh.fsf@tac.ki.iif.hu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, As pointed out by git-bisect, commit ecb44335 (mac80211: fix suspend/resume races with unregister hw) broke booting on my ThinkPad R50e. Looks like the rtnl_lock() around rdev->wiphy.registered = true leads to a deadlock, possibly because ipw2200 is built-in in my config. Testing with the additional debug patch [ 1.020738] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmpr [ 1.020812] ipw2200: Copyright(c) 2003-2006 Intel Corporation [ 1.023406] ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11 [ 1.025717] ipw2200 0000:02:02.0: PCI INT A -> Link[LNKF] -> GSI 11 (level, low ) -> IRQ 11 [ 1.028048] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection [ 1.148058] ------------[ cut here ]------------ [ 1.150393] WARNING: at net/wireless/core.c:619 wiphy_register+0x4c1/0x58c() [ 1.152781] Hardware name: 1834S5G [ 1.155126] Pid: 1, comm: swapper Not tainted 3.1.0-rc6+ #86 [ 1.157520] Call Trace: [ 1.159871] [] warn_slowpath_common+0x69/0x90 [ 1.162241] [] ? wiphy_register+0x4c1/0x58c [ 1.164617] [] ? wiphy_register+0x4c1/0x58c [ 1.166924] [] warn_slowpath_null+0x22/0x24 [ 1.169230] [] wiphy_register+0x4c1/0x58c [ 1.171564] [] ? ipw_net_init+0x1e6/0x2d0 [ 1.173890] [] ipw_net_init+0xab/0x2d0 [ 1.176173] [] register_netdevice+0x70/0x271 [ 1.178446] [] register_netdev+0x1b/0x28 [ 1.180688] [] ipw_pci_probe+0x7c3/0x891 [ 1.182892] [] local_pci_probe+0x40/0x9a [ 1.185086] [] pci_device_probe+0x56/0x71 [ 1.187259] [] driver_probe_device+0x6c/0x177 [ 1.189453] [] ? pci_match_device+0x80/0x85 [ 1.191615] [] __driver_attach+0x6c/0x6e [ 1.193794] [] bus_for_each_dev+0x4a/0x68 [ 1.195936] [] driver_attach+0x1e/0x20 [ 1.198043] [] ? driver_probe_device+0x177/0x177 [ 1.200151] [] bus_add_driver+0x186/0x231 [ 1.202247] [] ? pci_dev_put+0x16/0x16 [ 1.204320] [] driver_register+0x6a/0x118 [ 1.206386] [] ? misc_register+0xc2/0x133 [ 1.208425] [] ? parse_early_options+0x25/0x25 [ 1.210423] [] __pci_register_driver+0x33/0x8c [ 1.212393] [] ? parse_early_options+0x25/0x25 [ 1.214384] [] ipw_init+0x30/0x75 [ 1.216356] [] do_one_initcall+0x86/0x133 [ 1.218340] [] ? tun_init+0x8b/0x8b [ 1.220315] [] ? parse_early_options+0x25/0x25 [ 1.222270] [] kernel_init+0x75/0x10c [ 1.224214] [] kernel_thread_helper+0x6/0x10 [ 1.226124] ---[ end trace 4ef665623022622c ]--- [ 1.228121] ipw2200: Detected geography ZZR (14 802.11bg channels, 0 802.11a channels) in dmesg. It's a shoot in the dark, but register_netdev() issues rtnl_lock() before calling register_netdevice(), so wiphy_register() can't possibly acquire the rtnl mutex in the same call chain, or can it? --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -616,9 +616,8 @@ int wiphy_register(struct wiphy *wiphy) if (res) goto out_rm_dev; - rtnl_lock(); + WARN_ON(rtnl_is_locked()); rdev->wiphy.registered = true; - rtnl_unlock(); return 0; on top of c455ea4f (rc6+) leads to a working system with