netdev - Re: [External] Re: [PATCH net-next 2/3] selftests: fix OOM problem in msg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66171b8b595b_2d123b29472@willemb.c.googlers.com.notmuch>
Date: Wed, 10 Apr 2024 19:06:51 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Zijian Zhang <zijianzhang@...edance.com>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: netdev@...r.kernel.org, 
 davem@...emloft.net, 
 kuba@...nel.org, 
 cong.wang@...edance.com, 
 xiaochun.lu@...edance.com
Subject: Re: [External] Re: [PATCH net-next 2/3] selftests: fix OOM problem in
 msg_zerocopy selftest

> >>> In this case, for some reason, notifications do not
> >>> come in order now. We introduce "cfg_notification_order_check" to
> >>> possibly ignore the checking for order.
> >>
> >> Were you testing UDP?
> >>
> >> I don't think this is needed. I wonder what you were doing to see
> >> enough of these events to want to suppress the log output.
> 
> I tested again on both TCP and UDP just now, and it happened to both of 
> them. For tcp test, too many printfs will delay the sending and thus 
> affect the throughput.
> 
> ipv4 tcp -z -t 1
> gap: 277..277 does not append to 276

There is something wrong here. 277 clearly appends to 276

> gap: 276..276 does not append to 278

This would be an actual reordering. But the above line already
indicates that 276 is the next expected value.

> gap: 278..1112 does not append to 277
> gap: 1114..1114 does not append to 1113
> gap: 1113..1113 does not append to 1115
> gap: 1115..2330 does not append to 1114
> gap: 2332..2332 does not append to 2331
> gap: 2331..2331 does not append to 2333
> gap: 2333..2559 does not append to 2332
> gap: 2562..2562 does not append to 2560
> ...
> gap: 25841..25841 does not append to 25843
> gap: 25843..25997 does not append to 25842
> 
> ...
> 
> ipv6 udp -z -t 1
> gap: 11632..11687 does not append to 11625
> gap: 11625..11631 does not append to 11688
> gap: 11688..54662 does not append to 11632

If you ran this on a kernel with a variety of changes, please repeat
this on a clean kernel with no other changes besides the
skb_orphan_frags_rx loopback change.

It this is a real issue, I don't mind moving this behind cfg_verbose.
And prefer that approach over adding a new flag.

But I have never seen this before, and this kind of reordering is rare
with UDP and should not happen with TCP except for really edge cases:
the uarg is released only when both the skb was delivered and the ACK
response was received to free the clone on the retransmit queue.