Re: [net,v2] tcp: correct handling of extreme memory squeeze

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 24 Jan 2025 12:40:16 -0500
Jon Maloy <jmaloy@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