Re: [PATCH wireless 2/2] wifi: mt76: npu: read the rx slot count after the first slot is complete

[Florian Maurer]

On Fri, Nov 06, 2026 at 03:26:36PM +0100, Lorenzo Bianconi wrote:
> Relying on the patch I shared for 1/2, I guess this is no more a problem since
> we will just delay the skb allocation. Agree or am I missing something?

I think the race is still there. It is in the order of the two
descriptor reads, not in the skb allocation: your version still reads
PKT_COUNT from desc[q->tail].info first and checks DONE of that slot
afterwards. If the NPU completes the slot between the two reads, the
count is the 0 left by the memset in the refill, max_t() turns it into
1, and the DONE check then passes. A two-slot frame is delivered as one
slot, and its second slot is taken as the start of the next frame.

That matches what I saw on the W1700K: with patch 1 alone, 2-4 bogus
tx-free events per 30 minutes, each 2792 bytes over two slots
(1000 + 1792), i.e. the last slot of one frame plus the first slot of
the next. With patch 2, the same debug counter saw none in 60 minutes.

It gets worse once q->pending keeps the count across polls, as long as
the count is still read before DONE: a poll nearly always ends on a
first slot that is not done yet, so the frame that starts the next poll
would usually be stored with a count of 1. Checking DONE of the first
slot, then dma_rmb(), then reading PKT_COUNT avoids both. I sketched
it in my reply to 1/2:

https://lore.kernel.org/linux-wireless/20261108205350.2956138-1-fmaurer@xxxxxxxxxxx/

and v2 would carry it as one patch on top of your structure.

Thanks,
Florian