Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp246490pxb; Fri, 16 Apr 2021 04:48:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwHSEaflrKQcPPH1pPXZFYUBRuIN4Q0+W8dN1Vr8m4sDObLIdqKJ6saoIYUzLglH9C9Uc8L X-Received: by 2002:a17:902:8641:b029:e4:7e05:c916 with SMTP id y1-20020a1709028641b02900e47e05c916mr8790856plt.57.1618573699757; Fri, 16 Apr 2021 04:48:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618573699; cv=none; d=google.com; s=arc-20160816; b=YhecOLgzPnZUZvjt18RO+7sDlZ5v06HqOf80rpiYF33bJPzf2a1ondLveulfCe7cBW AX3QJQsmrN4XAmyhmf6IKSpqK7auE/+ERtH+2m1RDTAuETVQ4nvzg3eTBO/SnRyvzrhW rMtE9nGGw8BpXToIYyx+Ax+C2IJQoK8te71KeCbTNeEsZ6MWbxG+K5P2u0G8hCvc42sb 5RaiGpKV7lOy6+5FOCbkYKEvSoMHYZ4g8k5zoh8gt9DqJhtHgkVsxdix0o1TtgBca0b3 V3Q0++7BqPsKQqlrbQtPfwirQtjbYSoh46VSneWVDHBLeoJHLIO/Y5/vtjPhFyXT21DJ cEmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=NwhQKipNKbX3BgEtHeZXenbWEqzQMvMs3KY2FX3fnvg=; b=dsMep1KQrVFqGEOgc3JhvMWSGL30t2bbjcSWWdT6nac8UxE5yp9QP8/VYq+i1bWSXc GMNTa+K+/McnjOpoDgqD6/xI5ued/cmu/3MbqeABQ5kEFwXcZKRlRBbBG2Ihi8j2sLK/ 9k3OMM2CodcF1RKk/uEZ6IwsSED4PW4T5PwjQk8nxDDoJ4Xo/TUbCQ0PwZtNzhqNqzC/ rdZQBDvhej4LoU7lTHQckM05yq0c/r89HnfPstgodyOXmFeuq3+8TfUZALa0l/DwlSPw Aq4H7DIRWHY/o+ABIF3ylSHSck/Cyp07TDZPkSRc3DK9iJ2q/IC5exKAb2UkV5mbOhAs EsHg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a125si6312776pfa.240.2021.04.16.04.48.02; Fri, 16 Apr 2021 04:48:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240600AbhDPLri (ORCPT + 99 others); Fri, 16 Apr 2021 07:47:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240164AbhDPLrh (ORCPT ); Fri, 16 Apr 2021 07:47:37 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C92F0C061574 for ; Fri, 16 Apr 2021 04:47:12 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1lXMwI-00CXeP-1s; Fri, 16 Apr 2021 13:47:10 +0200 From: Johannes Berg To: linux-wireless@vger.kernel.org Cc: Johannes Berg Subject: [PATCH] mac80211: properly process TXQ management frames Date: Fri, 16 Apr 2021 13:47:04 +0200 Message-Id: <20210416134702.ef8486a64293.If0a9025b39c71bb91b11dd6ac45547aba682df34@changeid> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org From: Johannes Berg My previous commit to not apply flow control to management frames that are going over TXQs (which is currently only the case for iwlwifi, I think) broke things, with iwlwifi firmware crashing on certain frames. As it turns out, that was due to the frame being too short: space for the MIC wasn't added at the end of encrypted management frames. Clearly, this is due to using the 'frags' queue - this is meant only for frames that have already been processed for TX, and the code in ieee80211_tx_dequeue() just returns them. This caused all management frames to now not get any TX processing. To fix this, use IEEE80211_TX_INTCFL_NEED_TXPROCESSING (which is currently used only in other circumstances) to indicate that the frames need processing, and clear it immediately after so that, at least in theory, MMPDUs can be fragmented. Fixes: 73bc9e0af594 ("mac80211: don't apply flow control on management frames") Signed-off-by: Johannes Berg --- net/mac80211/tx.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 3d6c5b8ec0c2..8aeb60182f10 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1394,11 +1394,14 @@ static void ieee80211_txq_enqueue(struct ieee80211_local *local, * want to simplify the driver API by having them on the * txqi. */ - if (unlikely(txqi->txq.tid == IEEE80211_NUM_TIDS)) + if (unlikely(txqi->txq.tid == IEEE80211_NUM_TIDS)) { + IEEE80211_SKB_CB(skb)->control.flags |= + IEEE80211_TX_INTCFL_NEED_TXPROCESSING; __skb_queue_tail(&txqi->frags, skb); - else + } else { fq_tin_enqueue(fq, tin, flow_idx, skb, fq_skb_free_func); + } spin_unlock_bh(&fq->lock); } @@ -3587,10 +3590,16 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, /* Make sure fragments stay together. */ skb = __skb_dequeue(&txqi->frags); - if (skb) - goto out; + if (unlikely(skb)) { + if (!(IEEE80211_SKB_CB(skb)->control.flags & + IEEE80211_TX_INTCFL_NEED_TXPROCESSING)) + goto out; + IEEE80211_SKB_CB(skb)->control.flags &= + ~IEEE80211_TX_INTCFL_NEED_TXPROCESSING; + } else { + skb = fq_tin_dequeue(fq, tin, fq_tin_dequeue_func); + } - skb = fq_tin_dequeue(fq, tin, fq_tin_dequeue_func); if (!skb) goto out; -- 2.30.2