Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5825951ybp; Tue, 8 Oct 2019 08:52:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqxnLyKTg9VE3dKKXtexBWtK2Gs3bOg8Ii8/qZc8RX6yekfBwsSAEpcyovxQGys7VpAJtuxc X-Received: by 2002:a50:9fce:: with SMTP id c72mr2935921edf.166.1570549933751; Tue, 08 Oct 2019 08:52:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570549933; cv=none; d=google.com; s=arc-20160816; b=SebXwpA6ifmeADPY/CcH9/IT+/k28zBGsH3iFJYMkvV2oODSdOgB87C42oqqh94ctB 7YUTocuq9Ks3WkiQcarFa6CTdfkECr0Z9td+M+gegsyxH2mEqIhn2jOtu3yl5Cmiz/1i 0px+ejhm0g8BP7MeC7BjLD6PpfjKfIaA9tdK59ek/fVaAijrcej+z0QMi5agRy9AioXZ 07dvdePSPTBWnU9v9zW11cvkRp9bczuq6rxf5Nuovxrgdck1U/vy5yz9lkGPFXMuFs8r Pnsqi8LxbXmnyYt6rsVHeSJIqv3SE0b0XOcqIJ3SeDOP7FpmSzFh5R8UnmUcHNH+Btq8 7d+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:to:from:subject:message-id; bh=Fv+EpxyVwJnT7mcBc0P/AIWNnkDm9nMFY22JIB/8hrc=; b=D120Xmhw8VmSAib6GMkC11qe8LDF4FN7KFpJlNHRIk8otO0tOIVmrDcun4C8dQreO+ dPtst+DdECB7InsxWMClo5C8z7fAxB4XRbEPgkd9iTlRoB2xOfjdrUIN6zAn+2i+1K+O 5ucfbC6UxFbOvI3URBzZC4nkJN0krSHrJ0vsJb0TJK6jQmWnKzjo9va2ctR66NJpUq6q 8D1qmy96Wb4IRBMRvyIcoetCEECbojpm3UmL+mDtXT9FV1yuw7h+nIYki5y4gBATJgKc djD+/Otq30204craT1K3lrv3O2q/s7t5QoVyBAx+Hmq6VL+IdnutxVj4CkYsGeCmnSA9 iayw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g5si7669816ejp.430.2019.10.08.08.51.49; Tue, 08 Oct 2019 08:52:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727876AbfJHPtF (ORCPT + 99 others); Tue, 8 Oct 2019 11:49:05 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:41988 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726839AbfJHPtE (ORCPT ); Tue, 8 Oct 2019 11:49:04 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.2) (envelope-from ) id 1iHrjS-00038n-WA; Tue, 08 Oct 2019 17:49:03 +0200 Message-ID: <764782a00ba58b895add84ca87cc42db491c4e17.camel@sipsolutions.net> Subject: Re: [PATCH 2/2] mac80211: Support LIVE_ADDRESS_CHANGE feature From: Johannes Berg To: Denis Kenzior , James Prestwood , linux-wireless@vger.kernel.org Date: Tue, 08 Oct 2019 17:49:02 +0200 In-Reply-To: <2cf6ce4c-e9b7-9927-0f6f-52433ab3c66b@gmail.com> (sfid-20191008_173841_311495_63A9CFAA) References: <20190913195908.7871-1-prestwoj@gmail.com> <20190913195908.7871-2-prestwoj@gmail.com> <90ae00044bc0834d87d3f9fb75ce63dce4cfadd5.camel@gmail.com> <2cf6ce4c-e9b7-9927-0f6f-52433ab3c66b@gmail.com> (sfid-20191008_173841_311495_63A9CFAA) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi, > I concur that scanning should be checked as > if (sdata->local->scanning). So Johannes you're right that the polarity > is reversed. However, __ieee80211_start_scan seems to check for > local->scan_req instead to take deferred scans into account. So I > wonder if that is a better approach. Hmm. I don't think it's necessary. We basically only get to that kind of state if ieee80211_can_scan() returned false - then we assign local->scan_req and defer until ieee80211_run_deferred_scan() is called. But in the meantime, nothing in the scan requests references the MAC address. It does mean that we should grab local->mtx though for these checks, and then all around the interface change, so that we can be sure we don't actually start scanning in the middle of the changes here. johannes