From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794049075; b=gxiWL5CMNKY1PilClU+9GqBK2KXrcPCJ20fUGHmYdnMJI5p/c9OaUGPQH2y8hfLAO5oM fhmZqAJyNEsO4rCUYcnlS8dPz9TK1TJ6QE0d2bgctIjt8Je3BXp6ZATaJw64XqqcViZOg csPqr2sq84qivJ2bMusEg95W6Dn4vKUBFGaYLgi6n4Y+Vk+/NgBYPXkZEtwbO9DRJwwI8 +hG3bTIJ84KuwynFu+dMNJysJJxcDy6Es6tBYF02TpRWEDpZbzsSxCQKr8nVjTug/uUQC Ruh60JTGpH5dNg0pYjx3HfGnPAh6RgmcZgdd17i79UCxqJmuNuHvC1aRzgY09zBrIGQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794049075; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=gh56XFzgFeGMEHSJ45IzBBRj5ZJotmbnO+DMhzhwbTc=; b=Bn0+oaBnT37TXoPtgS3cbF/2mvetv6Z9NOirukAmx5qXbw+sgN6K8iCROgeUpmNRDNts 7b9VtEN1aUqjVqsOKTBse22V8FQMqG9bVwahiup7MIgODEhHm4deYLlV8kV9SZ2Nv5fxR ZAvgi8Ws/E/m9shU81bpzBWv0Ee8IZhu+81AoOv0x+3X7lHqZHdFSKRkVEbNvgadK3Wx3 brsmrsL+U9e4Zy7fa33s6p1YMdn8sROSkE13Z/3SAgXdGerfeX5yLYbZDc2/WLnXi+QiF HhwDXjCMJN98NuPPSx/MxOU2YMkz6mDm6mG28wZdcNVcPGhUn+/RykRuSAjEyN3G8Fg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=FkWZRI3o; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F236606A326 for ; Sat, 7 Nov 2026 10:57:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=FkWZRI3o Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E8161F008A1; Sat, 7 Nov 2026 10:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794049075; bh=gh56XFzgFeGMEHSJ45IzBBRj5ZJotmbnO+DMhzhwbTc=; h=From:To:Cc:Subject:Date; b=FkWZRI3orazz1okewbmC3/ghrgHEFoNNiwjUk7IlXRzMe96LMJJejaH0zZ5rNKWuN eoY3Fp+6ma+qumlG7+nVlQMG4NpASzs5NLN4DELoU/vVjI+evn8flDY7iuvE5Qs+Hk YygYbYr2crSIBM8kOqLiacXnxcZ7Ob9DqVpz56lEgFBS/tIymzSgGgNmmEP+AcmKFo 4iz+kvtHVUATdVv3M+w9ZSDdaeiUaWsP8kQOnlmdVVwqn6n7UfKqS2fzwWeK48/XXd 8KcYdBTlSJ0Cr5mKM6AkyQK8GMXGCxePKjkxbF8SV29MWACm3haei7B3nzQs0kKKWR +5CvnAFAHu2uA== From: Sasha Levin To: stf_xl@wp.pl, johannes.berg@intel.com Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] wifi: mac80211: queue frames while off-channel" failed to apply to 5.15-stable tree Date: Sat, 7 Nov 2026 05:57:53 -0500 Message-ID: <20261107055753-failed-5.15-13e51269b665@kernel.org> X-Mailer: git-send-email 2.53.0 X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 13e51269b6656768dc595ed6025e4974f2026543 # git commit -s git send-email --to '' --in-reply-to '20261107055753-failed-5.15-13e51269b665@kernel.org' --subject-prefix 'PATCH 5.15.y' 'HEAD^..' Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From 13e51269b6656768dc595ed6025e4974f2026543 Mon Sep 17 00:00:00 2001 From: Stanislaw Gruszka Date: Tue, 8 Sep 2026 14:46:51 +0200 Subject: [PATCH] wifi: mac80211: queue frames while off-channel Drivers without FAST_XMIT and hardware scan support currently drop TX frames during software scanning while being off-channel. This happens in ieee80211_tx_h_check_assoc() before frames reach internal TX queue. Move the off-channel check to invoke_tx_handlers_late(), after ieee80211_queue_skb(). Frames can then remain queued and be transmitted when the interface returns on-channel. This how TX works currently when code goes via ieee80211_xmit_fast() path. Below is rt2x00 driver ping output example while scanning, before and after the fix. After the fix, packets are no longer lost. Some have increased latency, what is expected behavior. BEFORE: 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.61 ms 64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=3.33 ms # Missed 30 64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.03 ms 64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=3.10 ms # Missed 33 64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=3.04 ms # Missed 35 64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.05 ms # Missed 37 64 bytes from 192.168.0.1: icmp_seq=40 ttl=64 time=4.14 ms # Missed 39 64 bytes from 192.168.0.1: icmp_seq=41 ttl=64 time=4.50 ms AFTER: 64 bytes from 192.168.0.1: icmp_seq=29 ttl=64 time=3.40 ms 64 bytes from 192.168.0.1: icmp_seq=30 ttl=64 time=6.10 ms 64 bytes from 192.168.0.1: icmp_seq=31 ttl=64 time=4.69 ms 64 bytes from 192.168.0.1: icmp_seq=32 ttl=64 time=4.49 ms 64 bytes from 192.168.0.1: icmp_seq=33 ttl=64 time=148 ms 64 bytes from 192.168.0.1: icmp_seq=34 ttl=64 time=6.83 ms 64 bytes from 192.168.0.1: icmp_seq=35 ttl=64 time=8.66 ms 64 bytes from 192.168.0.1: icmp_seq=36 ttl=64 time=13.0 ms 64 bytes from 192.168.0.1: icmp_seq=37 ttl=64 time=4.78 ms 64 bytes from 192.168.0.1: icmp_seq=38 ttl=64 time=3.85 ms Cc: Signed-off-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260908124651.2995-1-stf_xl@wp.pl Signed-off-by: Johannes Berg --- net/mac80211/tx.c | 52 +++++++++++++++++++++++++---------------------- 1 file changed, 28 insertions(+), 24 deletions(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index fd79814661376..d85c84a738f79 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -269,7 +269,6 @@ ieee80211_tx_h_dynamic_ps(struct ieee80211_tx_data *tx) static ieee80211_tx_result debug_noinline ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx) { - struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data; struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb); bool assoc = false; @@ -277,20 +276,6 @@ ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx) if (unlikely(info->flags & IEEE80211_TX_CTL_INJECTED)) return TX_CONTINUE; - if (unlikely(test_bit(SCAN_SW_SCANNING, &tx->local->scanning)) && - test_bit(SDATA_STATE_OFFCHANNEL, &tx->sdata->state) && - !ieee80211_is_probe_req(hdr->frame_control) && - !ieee80211_is_any_nullfunc(hdr->frame_control)) - /* - * When software scanning only nullfunc frames (to notify - * the sleep state to the AP) and probe requests (for the - * active scan) are allowed, all other frames should not be - * sent and we should not get here, but if we do - * nonetheless, drop them to avoid sending them - * off-channel. See __ieee80211_start_scan() for more. - */ - return TX_DROP; - if (tx->sdata->vif.type == NL80211_IFTYPE_OCB) return TX_CONTINUE; @@ -839,6 +824,33 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx) return TX_CONTINUE; } +static ieee80211_tx_result debug_noinline +ieee80211_tx_h_check_offchannel(struct ieee80211_tx_data *tx) +{ + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data; + struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb); + + if (unlikely(info->flags & IEEE80211_TX_CTL_INJECTED)) + return TX_CONTINUE; + + if (unlikely(test_bit(SCAN_SW_SCANNING, &tx->local->scanning)) && + test_bit(SDATA_STATE_OFFCHANNEL, &tx->sdata->state) && + !ieee80211_is_probe_req(hdr->frame_control) && + !ieee80211_is_any_nullfunc(hdr->frame_control)) { + /* + * When software scanning only nullfunc frames (to notify + * the sleep state to the AP) and probe requests (for the + * active scan) are allowed, all other frames should not be + * sent and we should not get here, but if we do + * nonetheless, drop them to avoid sending them + * off-channel. See __ieee80211_start_scan() for more. + */ + return TX_DROP; + } + + return TX_CONTINUE; +} + static __le16 ieee80211_tx_next_seq(struct sta_info *sta, int tid) { u16 *seq = &sta->tid_seq[tid]; @@ -1905,6 +1917,7 @@ static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx) goto txh_done; } + CALL_TXH(ieee80211_tx_h_check_offchannel); CALL_TXH(ieee80211_tx_h_michael_mic_add); CALL_TXH(ieee80211_tx_h_sequence); CALL_TXH(ieee80211_tx_h_fragment); @@ -4720,10 +4733,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata, queue = ieee80211_select_queue(sdata, sta, skb); skb_set_queue_mapping(skb, queue); - if (unlikely(test_bit(SCAN_SW_SCANNING, &local->scanning)) && - test_bit(SDATA_STATE_OFFCHANNEL, &sdata->state)) - goto out_free; - skb = skb_share_check(skb, GFP_ATOMIC); if (unlikely(!skb)) return; @@ -4785,11 +4794,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata, ieee80211_tpt_led_trig_tx(local, len); ieee80211_tx_8023(sdata, skb, sta, false); - - return; - -out_free: - kfree_skb(skb); } static bool ieee80211_check_mcast_offload(struct ieee80211_sub_if_data *sdata, -- 2.53.0