Re: [PATCH] wifi: iwlwifi: prevent NAPI processing after firmware error

[Cole Leavitt <cole@unwrap.rs>]

Ben,

Thanks for the historical context. I dug through the git history and
your linux-ct repos to verify exactly what happened when. I want to
make sure I have this right - can you confirm whether this matches
what you saw?

2018 Bug (Bug 199209)
---------------------
Fixed by Emmanuel in commit 0eac9abace16 ("iwlwifi: mvm: fix TX of
AMSDU with fragmented SKBs"). That was a different trigger - NFS
created highly fragmented SKBs where nr_frags was so high that the
buffer descriptor limit check produced num_subframes=0. Emmanuel's
fix clamps that path to 1.

Current MLD Bug
---------------
Different path to the same symptom. When TLC disables AMSDU for a
TID, both MVM and MLD set max_tid_amsdu_len[tid] = 1 as a sentinel
value. The key difference in protection:

MVM has a private mvmsta->amsdu_enabled bitmap that gates the entire
AMSDU path:

    if (!mvmsta->amsdu_enabled)
        return iwl_tx_tso_segment(skb, 1, ...);  // bail out early

    if (!(mvmsta->amsdu_enabled & BIT(tid)))
        return iwl_tx_tso_segment(skb, 1, ...);  // bail out early

MVM never reads max_tid_amsdu_len in its TX path - it uses its own
mvmsta->max_amsdu_len. This bitmap was added in commit 84226ca1c5d3
("iwlwifi: mvm: enable AMSDU for all TIDs", Nov 2017).

MLD was designed to use mac80211's sta->cur->max_tid_amsdu_len
directly, with no equivalent bitmap:

    max_tid_amsdu_len = sta->cur->max_tid_amsdu_len[tid];
    if (!max_tid_amsdu_len)  // only catches 0, not sentinel 1!
        return iwl_tx_tso_segment(skb, 1, ...);

    num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad);
    // When max_tid_amsdu_len=1: num_subframes = (1 + 3) / (1534 + 3) = 0

What I found in your repos:

  - linux-ct-6.5-be200, linux-ct-6.10, linux-ct-6.14: No MLD driver,
    only MVM with amsdu_enabled bitmap protection
  - linux-ct-6.15, linux-ct-6.18: Have MLD driver
    (drivers/net/wireless/intel/iwlwifi/mld/)
  - backport-iwlwifi: MLD tx.c first appeared in commit 56f903a89
    (2024-07-17)

So MVM should have been immune to this specific sentinel-value bug
due to the bitmap check.

Question for you: When you saw TSO segment explosions in 2024, what
kernel and driver were you using? If it was one of your 6.5-6.14
kernels with MVM, then there may be a different path to
num_subframes=0 that I haven't identified yet. If you were using
backport-iwlwifi with MLD enabled, that would explain it hitting the
same bug I'm fixing now.

The commit ae6d30a71521 (Feb 2024) added better error reporting for
skb_gso_segment failures, which suggests people were hitting GSO
segment errors around that time - but I don't have visibility into
what specific trigger you hit.

My fix catches the sentinel-induced zero after the calculation, which
is equivalent to what MVM's bitmap check accomplishes. This should
prevent the current MLD bug from reaching skb_gso_segment with
gso_size=0.

Looking forward to your test results with the problem AP, and any
clarification on what setup you were using in 2024.

Cole