Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Jan 2025 00:01:37 +0000
From:      bugzilla-noreply@freebsd.org
To:        wireless@FreeBSD.org
Subject:   [Bug 283903] rtw88: possible skb leak
Message-ID:  <bug-283903-21060-JYNDQx769D@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-283903-21060@https.bugs.freebsd.org/bugzilla/>
References:  <bug-283903-21060@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283903

--- Comment #9 from Guillaume Outters <guillaume-freebsd@outters.eu> ---
OK, I was wrong thinking the compiler eating mem induced rtw88 into error:
now I'm convinced that rtw88 ate so much mem that clang hadn't enough anymo=
re.

Twice this week I observed lpkiskb going rogue, unfortunately without detec=
ting
the precise moment it became Mr Hyde.

But (as seen in https://bz-attachments.freebsd.org/attachment.cgi?id=3D2567=
04),
I managed to test a loop of a 2 MB scp every minute, while watching vmstat =
-m |
grep lkpiskb,
with surprising results:

A. Before going rogue

Each scp added to the req counter, but memory stayed remarkably stable, at =
16
MB.
I didn't even noticed any temporary increase of mem use during scps (and
statistically, my probe every 10 seconds should have happened multiple times
simultaneously with my 4 seconds lasting download).

B. After having gone rogue

Now the reqs are still there (hopefully!), but **mem use increases of ~ 3,4
MB** per scp of 2 MB (/!\ those are file bytes, not bandwidth; and I don't =
know
the bandwidth / file bytes ratio of scp)

And having the server lag helped saw something more interesting, due to
multiple probes occurring during the transfer:
the 3,4 MB didn't follow a monotonic growth, but instead the mem use increa=
sed
considerably, and _only some_ mem got freed once scp finished.=20=20

---------------------------------------------------------------------------=
-----

Here a one-go increase (probes at :45 and :56, scp occured around between :=
47
and :51) (+ 3,4 MB):
2025-01-14 01:06:45             lkpiskb 329256  1361215488      9513310=20=
=20=20=20=20=20=20=20
+2      +8192   +212
2025-01-14 01:06:56             lkpiskb 330093  1364643840      9517636=20=
=20=20=20=20=20=20=20
+837    +3428352        +4326
2025-01-14 01:07:06             lkpiskb 330095  1364652032      9517845=20=
=20=20=20=20=20=20=20
+2      +8192   +209

Here a two-go (+ 5 MB - 1,6 MB):
2025-01-14 01:07:47             lkpiskb 330115  1364733952      9518743=20=
=20=20=20=20=20=20=20
+5      +20480  +223
2025-01-14 01:07:57             lkpiskb 331360  1369833472      9522027=20=
=20=20=20=20=20=20=20
+1245   +5099520        +3284
2025-01-14 01:08:07             lkpiskb 330958  1368186880      9523298=20=
=20=20=20=20=20=20=20
-402    -1646592        +1271
2025-01-14 01:08:17             lkpiskb 330964  1368211456      9523527=20=
=20=20=20=20=20=20=20
+6      +24576  +229

Another one-go (+ 6,8 MB - 3,4 MB):
2025-01-14 01:10:00             lkpiskb 331828  1371750400      9529814=20=
=20=20=20=20=20=20=20
+2      +8192   +217
2025-01-14 01:10:10             lkpiskb 333506  1378623488      9534152=20=
=20=20=20=20=20=20=20
+1678   +6873088        +4338
2025-01-14 01:10:20             lkpiskb 332671  1375203328      9534368=20=
=20=20=20=20=20=20=20
-835    -3420160        +216
2025-01-14 01:10:30             lkpiskb 332674  1375215616      9534584=20=
=20=20=20=20=20=20=20
+3      +12288  +216

Here periodic security on the server made it really hard for scp to finish,=
 and
let rtw88 free its mem:
2025-01-14 07:21:34             lkpiskb 586598  2415288320      11209247=20=
=20=20=20=20=20=20
        +291    +1191936        +933
2025-01-14 07:21:57             lkpiskb 587114  2417401856      11210910=20=
=20=20=20=20=20=20
        +516    +2113536        +1663
2025-01-14 07:22:23             lkpiskb 587579  2419306496      11212416=20=
=20=20=20=20=20=20
        +465    +1904640        +1506
2025-01-14 07:22:45             lkpiskb 587877  2420527104      11213510=20=
=20=20=20=20=20=20
        +298    +1220608        +1094
2025-01-14 07:23:07             lkpiskb 588170  2421727232      11214571=20=
=20=20=20=20=20=20
        +293    +1200128        +1061
2025-01-14 07:23:29             lkpiskb 588474  2422972416      11215673=20=
=20=20=20=20=20=20
        +304    +1245184        +1102
2025-01-14 07:23:49             lkpiskb 587441  2418741248      11216292=20=
=20=20=20=20=20=20
        -1033   -4231168        +619

---------------------------------------------------------------------------=
-----

while true ; do date "+%Y-%m-%d %H:%M:%S" ; vmstat -m | grep lkpi ; sleep 1=
0 ;
done | tee -a ~/tmp/depuisboot.log
awk < ~/tmp/depuisboot.log
'/^2025-/{h=3D$0}/lkpiskb/{variation=3D"+"(-use+$2)"\t+"(-mem+$3)"\t+"(-req=
+$4);gsub(/[+]-/,"-",variation);gsub(/
+/,"\t");print h"\t"$0"\t"variation;use=3D0+$2;mem=3D0+$3;req=3D0+$4}' | le=
ss

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283903-21060-JYNDQx769D>