From patchwork Sat Jul 25 08:54:13 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Berg X-Patchwork-Id: 37313 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n6P8sKBr023803 for ; Sat, 25 Jul 2009 08:54:20 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755188AbZGYIyO (ORCPT ); Sat, 25 Jul 2009 04:54:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753059AbZGYIyO (ORCPT ); Sat, 25 Jul 2009 04:54:14 -0400 Received: from xc.sipsolutions.net ([83.246.72.84]:49513 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752853AbZGYIyN (ORCPT ); Sat, 25 Jul 2009 04:54:13 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MUd19-0003cq-3Z; Sat, 25 Jul 2009 10:54:11 +0200 Subject: [PATCH] cfg80211: fix circular lock dependency (1) From: Johannes Berg To: John Linville Cc: linux-wireless , "Luis R. Rodriguez" Date: Sat, 25 Jul 2009 10:54:13 +0200 Message-Id: <1248512053.32151.49.camel@johannes.local> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Luis reported this lockdep complaint, that he had also reported earlier but when trying to analyse I had been locking at the wrong code, and never saw the problem: (slightly abridged) --- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.31-rc4-wl #6 ------------------------------------------------------- wpa_supplicant/3799 is trying to acquire lock: (cfg80211_mutex){+.+.+.}, at: [] cfg80211_get_dev_from_ifindex+0x1a/0x90 [cfg80211] but task is already holding lock: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.+.}: [] __lock_acquire+0xd76/0x12b0 [] lock_acquire+0xe3/0x120 [] mutex_lock_nested+0x44/0x350 [] rtnl_lock+0x12/0x20 [] nl80211_send_reg_change_event+0x1f5/0x2a0 [cfg80211] [] set_regdom+0x28e/0x4c0 [cfg80211] -> #0 (cfg80211_mutex){+.+.+.}: [] __lock_acquire+0xe3b/0x12b0 [] lock_acquire+0xe3/0x120 [] mutex_lock_nested+0x44/0x350 [] cfg80211_get_dev_from_ifindex+0x1a/0x90 [cfg80211] [] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211] [] nl80211_set_interface+0x3b/0x260 [cfg80211] When looking at the correct code, the problem is quite obvious. I'm not entirely sure which code paths lead here, so until I can analyse it better let's just use RCU to avoid the problem. Signed-off-by: Johannes Berg --- net/wireless/nl80211.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- wireless-testing.orig/net/wireless/nl80211.c 2009-07-25 10:49:13.000000000 +0200 +++ wireless-testing/net/wireless/nl80211.c 2009-07-25 10:49:24.000000000 +0200 @@ -4517,10 +4517,10 @@ void nl80211_send_reg_change_event(struc return; } - rtnl_lock(); + rcu_read_lock(); genlmsg_multicast_allns(msg, 0, nl80211_regulatory_mcgrp.id, - GFP_KERNEL); - rtnl_unlock(); + GFP_ATOMIC); + rcu_read_unlock(); return;