From patchwork Tue Apr 23 00:58:08 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Lamparter X-Patchwork-Id: 2475081 Return-Path: X-Original-To: patchwork-linux-wireless@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id C1F0ADF23A for ; Tue, 23 Apr 2013 00:58:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753354Ab3DWA6O (ORCPT ); Mon, 22 Apr 2013 20:58:14 -0400 Received: from mail-bk0-f50.google.com ([209.85.214.50]:55352 "EHLO mail-bk0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752967Ab3DWA6N (ORCPT ); Mon, 22 Apr 2013 20:58:13 -0400 Received: by mail-bk0-f50.google.com with SMTP id ik5so25966bkc.9 for ; Mon, 22 Apr 2013 17:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=n76ecEzspRXv6GVjUW5UBtvUPBEMnyRh9BaB6q1OWRA=; b=RJiEBFs4MCdHYOczwQ40HYwGGC+/J87lXo2XzkVNWcjMKJs7ftvVTMLfdvrAxms1B7 oeUISzoFAPLLVijlfnGYdC6rikbI1UK6gcmTlilygHK7Bdn41Cc3BSbz1PfBA8wUIPkz AQjAYO85LuA+LWkIhwJdE5xoj4X+hVa3993x6fyxh/F0JQdVxSN7LILjFDj+5n4xgREp 4iTeqyUBPqqN91FkfkCWYTtATKwUm1+xe24bbhN9STLYBjWmD4seCF/KCjXAagsQK2LK vcjbBaPW3NPhEj2e44H1T4BOYqf0tty6v42Ii8Ax99ZjM9rit9zcj8f5G9IT1AhlcGu1 fzhA== X-Received: by 10.204.201.1 with SMTP id ey1mr12137975bkb.110.1366678692164; Mon, 22 Apr 2013 17:58:12 -0700 (PDT) Received: from blech.mobile (f053210179.adsl.alicedsl.de. [78.53.210.179]) by mx.google.com with ESMTPS id fe8sm3687449bkb.9.2013.04.22.17.58.10 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 17:58:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blech.mobile (Postfix) with ESMTP id 00C611003E2; Tue, 23 Apr 2013 02:58:09 +0200 (CEST) Received: from blech.mobile ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNj3BU2EShLy; Tue, 23 Apr 2013 02:58:08 +0200 (CEST) Received: from blech.localnet (localhost [127.0.0.1]) by blech.mobile (Postfix) with ESMTP id 7A36610027F; Tue, 23 Apr 2013 02:58:08 +0200 (CEST) From: Christian Lamparter To: Felix Fietkau Subject: [PATCH] mac80211: fix spurious use of rcu_dereference Date: Tue, 23 Apr 2013 02:58:08 +0200 User-Agent: KMail/1.13.7 (Linux/3.9.0-rc8-wl+; KDE/4.8.4; x86_64; ; ) Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net, karl.beldan@gmail.com References: <1366640083-1054-1-git-send-email-nbd@openwrt.org> In-Reply-To: <1366640083-1054-1-git-send-email-nbd@openwrt.org> MIME-Version: 1.0 Message-Id: <201304230258.08359.chunkeey@googlemail.com> Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org This patch fixes the following RCU debug splat: --- 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: suspicious RCU usage. ] 3.9.0-rc8-wl+ #31 Tainted: G O ------------------------------- net/mac80211/rate.c:691 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 3 locks held by hostapd/9451: #0: (genl_mutex){+.+.+.}, at: [] genl_lock+0xf/0x11 #1: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0xf/0x11 #2: (&rdev->mtx){+.+.+.}, at: [] nl80211_pre_doit+0x166/0x180 [cfg80211] stack backtrace: Pid: 9451, comm: hostapd Tainted: G O 3.9.0-rc8-wl+ #31 Call Trace: [] lockdep_rcu_suspicious+0xe6/0xee [] rate_control_set_rates+0x43/0x5a [mac80211] [] minstrel_update_rates+0xdc/0xe2 [mac80211] [] minstrel_rate_init+0x24c/0x33d [mac80211] [] minstrel_ht_update_caps+0x206/0x234 [mac80211] [] ? lock_release+0x1c9/0x226 [] minstrel_ht_rate_init+0x10/0x14 [mac80211] [...] Signed-off-by: Christian Lamparter --- Actually, rcu_read_lock() might not be necessary in this special case [the RC is not yet initialized, so nothing bad can happen]. But, since the rcu_read_lock() has a low overhead and rate_control_set_rates mac80211.h doc does not mention anything about locking, I think this is a viable way. --- diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c index 0d51877..615d3a8 100644 --- a/net/mac80211/rate.c +++ b/net/mac80211/rate.c @@ -688,11 +688,15 @@ int rate_control_set_rates(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta, struct ieee80211_sta_rates *rates) { - struct ieee80211_sta_rates *old = rcu_dereference(pubsta->rates); + struct ieee80211_sta_rates *old; + + rcu_read_lock(); + old = rcu_dereference(pubsta->rates); rcu_assign_pointer(pubsta->rates, rates); if (old) kfree_rcu(old, rcu_head); + rcu_read_unlock(); return 0; }