Re: [PATCH wireless-next] wifi: mac80211: Fix ADDBA request rejection after MLD link removal

[Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>]

On 4/27/2026 3:30 PM, Johannes Berg wrote:
> On Wed, 2026-04-15 at 12:21 +0530, Manish Dharanenthiran wrote:
>> From: Hari Naraayana Desikan Kannan <hnaraaya@qti.qualcomm.com>
>>
>> Subsequent ADDBA requests from a non-AP MLD can be rejected with status
>> 0x0025 (Request declined), preventing BA establishment. This happens
>> because mac80211 checks the per-TID A-MPDU session's tid_rx pointer to
>> detect timeout changes on ADDBA updates. For drivers that set
>> SUPPORT_REORDERING_BUFFER, the reordering state is owned by the driver
>> and tid_rx will be NULL, causing mac80211 to incorrectly decline the
>> update.
>>
>> This can occur during MLO link reconfiguration, where a non-AP MLD may
>> remove one of its links while a Block Ack (BA) session is active. After
>> the link is removed, ADDBA update requests sent on the remaining links
>> are rejected, preventing BA establishment.
>>
>> Fix this by calling drv_ampdu_action() on ADDBA updates when
>> SUPPORT_REORDERING_BUFFER is set, so the driver can accept or reject the
>> update based on its capabilities and allow BA to be established on the
>> remaining links.
> 
> Pretty sure this will break drivers, particularly iwlwifi, if you don't
> fix those first.
> 


With link reconfiguration, not handling the update requests sent on the 
remaining links causes throughput drop, that's why went with handling 
the update requests even-though the session is valid.
Please let us know if we need to clear the old session and then proceed 
with the update request to avoid breaking the other drivers.
>> Note: A similar fix has been proposed in [1]. This patch also fixes the
>> issue mentioned there. The difference in approach is to keep a similar
>> flow when the dialog_token matches. Previously only the timeout value
>> is checked, updated that to check the timeout only for the hardware that
>> doesn't set SUPPORT_REORDERING_BUFFER. In [1], it was changed to invoke
>> driver unconditionally when SUPPORT_REORDERING_BUFFER is set.
>>
>> https://lore.kernel.org/all/5806bab7e46506d3c300ab4eb66989d42936aeb0.1771323902.git.repk@triplefau.lt/
>>
> What was wrong with the approach we discussed there, other than nobody
> implementing it?
> 
> johannes

Not a major different between the other change, thought of keeping the 
similar version that we validated in the internal tree.

Regards
Manish Dharanenthiran