From nobody Fri Apr 22 05:49:14 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 509AB19926B1; Fri, 22 Apr 2022 05:49:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kl3Pl1nfNz4TS0; Fri, 22 Apr 2022 05:49:15 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650606555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=pSbXeh+42NMhD9Q1D8/JYRNuUaImP6pFE1WY3HL7h34=; b=X5bdyb4QpUcjAWSjJN+UVev6IzKEks2m6YHsdtosFAJ8DfheEfeR7XpbdUjro58lj6l5my oBMpvyem4gIYxN89J+k2S89J1vYyk55VT1MYq4p8ON+cz8BWzds2jFcSANb5gvZuv8uYHo U+jpzUJiuv8yl58nFaLPZ/jtsxpvS9T5tczljl2WFQIATU62gn/QO2WmRxmHd/gGu2Ynnk qJOmQukd2JJFmuewvSdzDQpnw9vBgjmX1X0pNngmM+lCm1CkQrsk85tXFeKytU1RWnCrL6 dKAPHxUQ1+uoNxMYj48i/jwTaxDsTXsoAfeQHhE6SZcH3VdYj7fNwtI+8cS2Zg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0F7A4173FA; Fri, 22 Apr 2022 05:49:15 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 23M5nE5B099683; Fri, 22 Apr 2022 05:49:14 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 23M5nEhP099682; Fri, 22 Apr 2022 05:49:14 GMT (envelope-from git) Date: Fri, 22 Apr 2022 05:49:14 GMT Message-Id: <202204220549.23M5nEhP099682@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org From: Adrian Chadd Subject: git: e8de31caceaa - main - net80211: Fix traffic hang on STA/AP VAPs on a multi-VAP interface List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: adrian X-Git-Repository: src X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e8de31caceaa36caf5d7b4355072f148e2433b82 Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650606555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=pSbXeh+42NMhD9Q1D8/JYRNuUaImP6pFE1WY3HL7h34=; b=PLRTB7Ed3VXHw+XI24RTG5GK5ZjnOk+Qz+tS/Z72dHbgwqNmarRmIE4ly+O9aO9myXbXdk UEL/mIcM25aFKYVc12rotcK03n++aohojCQcVked4BQm+O/wgDek21Sd7UgIgN8QW/Xi2T KSih3fKICS1VlzaMCAHc8YftF1CZV82/HHaPm+4HaD94vCH8O+9zJA8YQslM4gmLO6CxjE i63upldaCv5yxK0mfxi7a+aPr4eKIP1/cOxojUQeeb0Hb8F3eyopExrQ9jQjp4XU8D9vtS oGlWPbEAS9svKn0CNK9/bNiUFS3XsMgxlIwCSUbkSifGJ4rNK06MD/9nOr84eA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650606555; a=rsa-sha256; cv=none; b=KD90z62QHWG3uBHcGc0sL828O1jDWOEsDuhAE4ubXQY2kGzCu2Qy+lv6HQURF2HaUGenZG yD/rv3vS9iDGoKmmZATylGSduF6nqtgDuujuDCJ7F89+ceiu2EEeWTUlsHAQR2BisJi/oG Bl4NTm3rx1sJh2sSJD0QvyPyYWYmn0/WdnB2au3sOMGCimwcCHl8afBORqIjD2ggkGEoFg 1FzUmoXriyknFq8GMKNGtPvzrWcs/wVsMQaDm1d7yi7d+cKU9Wt6iw58Z1KjmRlRZVu+GP KYOboX/Gz9n1xrq3/r/9ikD66rorc9zdv760PiuKGJQ/ynehW6LBYe2oC3QFQA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by adrian: URL: https://cgit.FreeBSD.org/src/commit/?id=e8de31caceaa36caf5d7b4355072f148e2433b82 commit e8de31caceaa36caf5d7b4355072f148e2433b82 Author: Adrian Chadd AuthorDate: 2022-04-12 20:20:28 +0000 Commit: Adrian Chadd CommitDate: 2022-04-22 05:49:01 +0000 net80211: Fix traffic hang on STA/AP VAPs on a multi-VAP interface This took an embarrasingly long time to find. The state changes for a radio with a STA /and/ AP VAP gets a bit messy. The AP maps are marked as waiting, waiting for the STA AP to find a channel to use before the AP VAPs become active. However, the code path that clears the OACTIVE flag on a VAP only runs during a successful run of ieee80211_newstate_cb(). So here is how it goes: * the STA VAP goes down and needs to scan; * the AP vap goes RUN->INIT; but it doesn't YET call ieee80211_newstate_cb(); * meanwhile - a send on the AP VAP causes the VAP to set the OACTIVE flag here; * then the STA VAP finishes scan and goes to RUN; * which will call wakeupwaiting() as part of the STA VAP transition to RUN; * .. then the AP VAP goes INIT->RUN directly via a call to hostap_newstate in wakeupwaiting rather than it being through the deferred path; * /then/ the ieee80211_newstate_cb() is called, but it sees the state go RUN->RUN; * .. which results in the OACTIVE flag never being cleared. This clears the OACTIVE flag when a VAP transitions RUN->RUN; the driver layer or net80211 layer can set it if required in a subsequent transmit. Differential Revision: https://reviews.freebsd.org/D34920 Reviewed by: bz --- sys/net80211/ieee80211_proto.c | 47 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/sys/net80211/ieee80211_proto.c b/sys/net80211/ieee80211_proto.c index 2228983050a2..d2bde99ce79c 100644 --- a/sys/net80211/ieee80211_proto.c +++ b/sys/net80211/ieee80211_proto.c @@ -2469,6 +2469,29 @@ wakeupwaiting(struct ieee80211vap *vap0) vap->iv_flags_ext &= ~IEEE80211_FEXT_SCANWAIT; /* NB: sta's cannot go INIT->RUN */ /* NB: iv_newstate may drop the lock */ + + /* + * This is problematic if the interface has OACTIVE + * set. Only the deferred ieee80211_newstate_cb() + * will end up actually /clearing/ the OACTIVE + * flag on a state transition to RUN from a non-RUN + * state. + * + * But, we're not actually deferring this callback; + * and when the deferred call occurs it shows up as + * a RUN->RUN transition! So the flag isn't/wasn't + * cleared! + * + * I'm also not sure if it's correct to actually + * do the transitions here fully through the deferred + * paths either as other things can be invoked as + * part of that state machine. + * + * So just keep this in mind when looking at what + * the markwaiting/wakeupwaiting routines are doing + * and how they invoke vap state changes. + */ + vap->iv_newstate(vap, vap->iv_opmode == IEEE80211_M_STA ? IEEE80211_S_SCAN : IEEE80211_S_RUN, 0); @@ -2543,6 +2566,30 @@ ieee80211_newstate_cb(void *xvap, int npending) goto done; } + /* + * Handle the case of a RUN->RUN transition occuring when STA + AP + * VAPs occur on the same radio. + * + * The mark and wakeup waiting routines call iv_newstate() directly, + * but they do not end up deferring state changes here. + * Thus, although the VAP newstate method sees a transition + * of RUN->INIT->RUN, the deferred path here only sees a RUN->RUN + * transition. If OACTIVE is set then it is never cleared. + * + * So, if we're here and the state is RUN, just clear OACTIVE. + * At some point if the markwaiting/wakeupwaiting paths end up + * also invoking the deferred state updates then this will + * be no-op code - and also if OACTIVE is finally retired, it'll + * also be no-op code. + */ + if (nstate == IEEE80211_S_RUN) { + /* + * Unblock the VAP queue; a RUN->RUN state can happen + * on a STA+AP setup on the AP vap. See wakeupwaiting(). + */ + vap->iv_ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + } + /* No actual transition, skip post processing */ if (ostate == nstate) goto done;