From nobody Fri Jun 03 17:19:18 2022 X-Original-To: dev-commits-src-all@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 4A7AD1BDA660; Fri, 3 Jun 2022 17:19:20 +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 4LF8kb6sjgz4XWr; Fri, 3 Jun 2022 17:19:19 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654276760; 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=dZaP9hzUFRt3K+iBm24tCqAPpBehGYORiCUim6MA5YY=; b=LkQL59K/ABHgq80OS4rkfmgC2bs+X2VFljy74UXR2LvS6DC8gT5b0OfZpq9wHoCi3L170d 1bn9nl/KkkcylVQC7j5b390iajUgLsOi6l1d6jfztW20HgIud5585R4xlP6xDjPnOn2byg q6EtciUFf+0qyevAmyDMZv3dM6rnGO9yYrhAWlZHBZ5tRAOI+NYMJa6Q7OIj2RgoJ3uEnm y7VTzuxB98al+5Jnqg+1f6I6Cc006ImqxGgsYHk/hOay1D8diY+MunF1Jvxw/jJXD/t+tw TwI7Z006nYqmm+lYPqfLRHAuONNLP7MMfqN1lv/jCXCVPoQaAHvoxC4b8Zjc+A== 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 82374564D; Fri, 3 Jun 2022 17:19:19 +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 253HJJ2d065602; Fri, 3 Jun 2022 17:19:19 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 253HJIKV065601; Fri, 3 Jun 2022 17:19:18 GMT (envelope-from git) Date: Fri, 3 Jun 2022 17:19:18 GMT Message-Id: <202206031719.253HJIKV065601@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org From: "Bjoern A. Zeeb" Subject: git: d672853b6cf1 - stable/13 - net80211: Fix traffic hang on STA/AP VAPs on a multi-VAP interface List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: bz X-Git-Repository: src X-Git-Refname: refs/heads/stable/13 X-Git-Reftype: branch X-Git-Commit: d672853b6cf15a8bf33f594b4b1fdc0c0d12ce86 Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654276760; 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=dZaP9hzUFRt3K+iBm24tCqAPpBehGYORiCUim6MA5YY=; b=PyzI59l4xyfAno+MX/j5z27ez1P7q0cW+9cofZ3T0obMVDvdaPKCTldA0D81qFtL+sPoOB uBGzWnnbnEZx2Z/F1qW4dZ+5nAinsU8fTP8MGTmAuj6Hk0AqncEw4KVIIFjEi9nIUoljTh rC2jOUbly//xyxJOBg4B72ALm1YI5Z9awT2c63Rj2vOBJFP2YmBTCuKMjnseGQ+b5RWO4f YefZRhdCkfBo+mcfjYhyPn5aH4hmHTsGv4FDdpT2UobitOS2iAhYZMOXqlj09/FywuzSVc NI1cMt528/B6iLx7rcDCaFrupDAceSk9xZvNETFtdPMXfUKMaF8DsSO4KtdEXg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654276760; a=rsa-sha256; cv=none; b=C1sZ7ovcWprMSKcXXJjvpqfBjq5CTewQ98haaYbkgpc29I6/ZRFPDDkM0mBb6T6Ri65G8q BEgJjNxV0k3unzN5pCZ2LdKGE5Ax5xCEZNrxPSY4Gvg4SobN8a0LEHg0LLoi+Ns4/3tf+i 4hLPfn64Wu6WQaM0ggi/xpBUeB4nlef6io3nZgmr7/5s1Ri93xRG+Y5wmndj7ZQQykaUKa Pnf1ruGX1RfBiU32FHVl8uIhjyi6YyxYYWCP+Vm6jMix6nqqxYS9Y3zqnohn5hyspQ0DIW gRXDrnfBrgjKEMEx2MeOIUUZsbZ0ksiw2FdxGl7hKPKzS8/XzKK2e2fqJyEAFA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N The branch stable/13 has been updated by bz: URL: https://cgit.FreeBSD.org/src/commit/?id=d672853b6cf15a8bf33f594b4b1fdc0c0d12ce86 commit d672853b6cf15a8bf33f594b4b1fdc0c0d12ce86 Author: Adrian Chadd AuthorDate: 2022-04-12 20:20:28 +0000 Commit: Bjoern A. Zeeb CommitDate: 2022-06-03 16:55:44 +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 (cherry picked from commit e8de31caceaa36caf5d7b4355072f148e2433b82) --- 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;