On Fri, 24 Jan 2025 12:40:16 -0500 Jon Maloy <jmaloy(a)redhat.com> wrote:I can certainly clear tp->pred_flags and post it again, maybe with an improved and shortened log. Would that be acceptable?Talking about an improved log, what strikes me the most of the whole problem is: $ tshark -r iperf3_jon_zero_window.pcap -td -Y 'frame.number in { 1064 .. 1068 }' 1064 0.004416 192.168.122.1 → 192.168.122.198 TCP 65534 34482 → 5201 [ACK] Seq=1611679466 Ack=1 Win=36864 Len=65480 1065 0.007334 192.168.122.1 → 192.168.122.198 TCP 65534 34482 → 5201 [ACK] Seq=1611744946 Ack=1 Win=36864 Len=65480 1066 0.005104 192.168.122.1 → 192.168.122.198 TCP 56382 [TCP Window Full] 34482 → 5201 [ACK] Seq=1611810426 Ack=1 Win=36864 Len=56328 1067 0.015226 192.168.122.198 → 192.168.122.1 TCP 54 [TCP ZeroWindow] 5201 → 34482 [ACK] Seq=1 Ack=1611090146 Win=0 Len=0 1068 6.298138 fe80::44b3:f5ff:fe86:c529 → ff02::2 ICMPv6 70 Router Solicitation from 46:b3:f5:86:c5:29 ...and then the silence, 192.168.122.198 never announces that its window is not zero, so the peer gives up 15 seconds later: $ tshark -r iperf3_jon_zero_window_cut.pcap -td -Y 'frame.number in { 1069 .. 1070 }' 1069 8.709313 192.168.122.1 → 192.168.122.198 TCP 55 34466 → 5201 [ACK] Seq=166 Ack=5 Win=36864 Len=1 1070 0.008943 192.168.122.198 → 192.168.122.1 TCP 54 5201 → 34482 [FIN, ACK] Seq=1 Ack=1611090146 Win=778240 Len=0 Data in frame #1069 is iperf3 ending the test. This didn't happen before e2142825c120 ("net: tcp: send zero-window ACK when no memory") so it's a relatively recent (17 months) regression. It actually looks pretty simple (and rather serious) to me. -- Stefano