From patchwork Fri Jun 18 10:41:37 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luca Coelho X-Patchwork-Id: 12331069 X-Patchwork-Delegate: johannes@sipsolutions.net Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18EB3C48BE8 for ; Fri, 18 Jun 2021 11:06:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E9AF16128C for ; Fri, 18 Jun 2021 11:06:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231838AbhFRLIp (ORCPT ); Fri, 18 Jun 2021 07:08:45 -0400 Received: from paleale.coelho.fi ([176.9.41.70]:48280 "EHLO farmhouse.coelho.fi" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S231810AbhFRLIp (ORCPT ); Fri, 18 Jun 2021 07:08:45 -0400 Received: from 91-156-6-193.elisa-laajakaista.fi ([91.156.6.193] helo=kveik.lan) by farmhouse.coelho.fi with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1luBww-001YXx-Kd; Fri, 18 Jun 2021 13:42:12 +0300 From: Luca Coelho To: johannes@sipsolutions.net Cc: luca@coelho.fi, linux-wireless@vger.kernel.org Date: Fri, 18 Jun 2021 13:41:37 +0300 Message-Id: X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210618104156.747775-1-luca@coelho.fi> References: <20210618104156.747775-1-luca@coelho.fi> MIME-Version: 1.0 Subject: [PATCH 12/31] mac80211: Properly WARN on HW scan before restart Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org From: Ilan Peer The following race was possible: 1. The device driver requests HW restart. 2. A scan is requested from user space and is propagated to the driver. During this flow HW_SCANNING flag is set. 3. The thread that handles the HW restart is scheduled, and before starting the actual reconfiguration it checks that HW_SCANNING is not set. The flow does so without acquiring any lock, and thus the WARN fires. Fix this by checking that HW_SCANNING is on only after RTNL is acquired, i.e., user space scan request handling is no longer in transit. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho --- net/mac80211/main.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/net/mac80211/main.c b/net/mac80211/main.c index 62145e5f9628..da3e0ca6aa31 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -256,14 +256,13 @@ static void ieee80211_restart_work(struct work_struct *work) /* wait for scan work complete */ flush_workqueue(local->workqueue); flush_work(&local->sched_scan_stopped_work); + flush_work(&local->radar_detected_work); + + rtnl_lock(); WARN(test_bit(SCAN_HW_SCANNING, &local->scanning), "%s called with hardware scan in progress\n", __func__); - flush_work(&local->radar_detected_work); - /* we might do interface manipulations, so need both */ - rtnl_lock(); - wiphy_lock(local->hw.wiphy); list_for_each_entry(sdata, &local->interfaces, list) { /* * XXX: there may be more work for other vif types and even