[Bug 283903] rtw88: possible skb leak

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283903

--- Comment #26 from Guillaume Outters <guillaume-freebsd@outters.eu> ---
(I have not progressed; however now that my laptop is my main machine, the bug
starts to be really annoying, with 1 or 2 reboots required by day as you may
have Oleg)

And I've attempted reorganizing my previous comment, which could give a clearer
view of the process.

So, based on my previous path codes A1, A2 for allocations, and D1.1, D1.2, D2
and D3 for deallocs:

(all subsequent distributions apply to RX as well as TX, with only numbers
differing, for an scp of a 10 MiB file)

I. When running normally after a reboot

A1   4364 (RX) / 7251 (TX)
D1.1 same numbers
A2   17870 (RX) / 20255 (TX)
D2   12000 to 13000
D1.2 4364 (RX) / 7251 (TX)

with A1 = D1.1, and A2 = D2 + D1.2

II. When running in anomally

A1   4678 (RX) / 7225 (TX)
                                  (no D1.1)
A2   17869/70
D2   10000 to 13000
                                  (no D1.2)
D3   4678 (RX) / 7225 (TX)

So, no call to D1 (neither D1.1 nor D1.2), but a D3 to compensate __only D1.2__
(and asynchronous: sometimes only 30 s after the corresponding Ax)

III. Conclusion

D3 (softclock_call_cc+0x12c > rtw_tx_report_purge_timer+0x8e) seems to be a
degraded mode under load (no time to call D1 anymore, it is stacked for
later?), which works well but **ONLY COMPENSATES ONE OF THE TWO FREEs NORMALLY
CALLED WITHIN D1**.

Said otherwise: D1 coordinates freeing of SKB allocated within both A2
(lkpi_napi_task+0xf) and A1 (lkpi_80211_txq_task+0x1ec) (which are related, as
we have as many A1-allocated SKB as we have from A2);
while D3 (that seems to be designed to take the relay of D1 in case of heavy
load), only frees one of those two SKB.

-- 
You are receiving this mail because:
You are on the CC list for the bug.