From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: passt.top; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=LPCvNm3j; dkim-atps=neutral Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by passt.top (Postfix) with ESMTPS id 8EAA55A061E for ; Mon, 27 Jan 2025 11:18:06 +0100 (CET) Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-844e7409f8aso109882639f.1 for ; Mon, 27 Jan 2025 02:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737973085; x=1738577885; darn=passt.top; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=f83p5LEi6LREo/dGN0fkA5HAxyKgSt/xyMs2Ty5texg=; b=LPCvNm3jRP+fwgGY728XZlx+PEYrJiNsBbt3boArL0hoySKfVPQDCb3HlYYirJ1IiY KuEF7pmLOjdf1TbESk9M487x3MzCskuedsi1X2wztE+QBEOFjXCvru9goSCR2gF4zOb/ h8sHwOR/7mOr/qwngQ4Zk7Fn1nX6h7y8IKX+YoIcNdjgVD1MM0dWO/zH1tvtDp0YNOkk Bh8lPSeOyDZbCt6ygzD1TaReTZBXGktqBxGMbfyF9W+eJqr2y30ajC9hDLZQCkNtRQVP W2ehBZ9YcGF5KYJiI7y/WdaneVp4XNapgtsq11kDUePg/7MJGXJyQtYEbeiw0K/872g/ mxQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737973085; x=1738577885; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=f83p5LEi6LREo/dGN0fkA5HAxyKgSt/xyMs2Ty5texg=; b=v/UZwVRsrTGtbNYJHno/RUI2jOUsAklYIzAw7jXsTjTh8cTESsSu4anYAvGPpiRyWA 5ptaNp7aAmRpuV1J4fENaZFpE0tqTblwa99Hi+Yd1Y+q6VaRiq6H75KXlzRGMueLJZIn euhrefdzgaOiAX2V+mkW1t1hO5m5dBsVHWfusljIULgs69QW+/hOhZyhxq7zBc5Z2W4p dRt3tZX7Gy/jZTuucu2s+KImq3Zwm2yUpu8uWFNIOjj3FSPGJM1itWOrVfCXZGupiTcw BOtoIxv8pt9FmORiiDgVILaDi9spp12QOGnOJCRq+FbLzudkel03fJXWcI5M9BdUvN65 /RJA== X-Forwarded-Encrypted: i=1; AJvYcCUSkyWpM+Hxaks/z5d2rlhxJFRXrvgGgDHoZRvQUj4m3PQgcU4zM1FA0mAOXcKUso8GY4J+hB4k/wQ=@passt.top X-Gm-Message-State: AOJu0Yz5VY7pJ17dc+VgO7/Fv6jzdtFov3gKHSWPqSM5dPWJhX8IAAEJ 7nG/o+uwCudmm3tKutyhLed5GsTHNV15JTn67jyythg124vc+g/NuA7FnotQm8wI3o4ovWP5Mn7 AvgHOawjW58iPWUhb9vZisoaw0Xk= X-Gm-Gg: ASbGncv1PYwD9Yqhd44+fkizrcBGFc8/TM0Pg+/iBp3vNfezr/vB+foSReZv1WTGVa3 buHz1XRDPiItl+PbRyIN9BJpXFjx4/8/KdxOh//biI04LZV2dE3tCoICjV8lSkQ== X-Google-Smtp-Source: AGHT+IFseuO1vkGe/S2I2g1JMJFHXZwOmgMhhMF3UaPW1yv1KC5g0gWY1dK7MYuoTshFS3lQlSUs1ObXFUGwuS1pO80= X-Received: by 2002:a92:c248:0:b0:3cf:cbac:3ba6 with SMTP id e9e14a558f8ab-3cfcbac3c55mr84793075ab.5.1737973085242; Mon, 27 Jan 2025 02:18:05 -0800 (PST) MIME-Version: 1.0 References: <20250117214035.2414668-1-jmaloy@redhat.com> <20250127110121.1f53b27d@elisabeth> In-Reply-To: <20250127110121.1f53b27d@elisabeth> From: Jason Xing Date: Mon, 27 Jan 2025 18:17:28 +0800 X-Gm-Features: AWEUYZkVcPpH3BIgYw77883RR7hoXgzNe1BSS0KLljI3aSPPtvfryiB02dicy7U Message-ID: Subject: Re: [net,v2] tcp: correct handling of extreme memory squeeze To: Stefano Brivio Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-MailFrom: kerneljasonxing@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: QWECAEWIXB3YZFNI34GVNPPPNCE6WPAH X-Message-ID-Hash: QWECAEWIXB3YZFNI34GVNPPPNCE6WPAH X-Mailman-Approved-At: Mon, 27 Jan 2025 18:12:04 +0100 CC: Jon Maloy , Eric Dumazet , Neal Cardwell , netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org, passt-dev@passt.top, lvivier@redhat.com, dgibson@redhat.com, eric.dumazet@gmail.com, Menglong Dong X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, Jan 27, 2025 at 6:01=E2=80=AFPM Stefano Brivio = wrote: > > On Fri, 24 Jan 2025 12:40:16 -0500 > Jon Maloy 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 =E2=86=92 192.168.122.198 TCP 65534 34482 = =E2=86=92 5201 [ACK] Seq=3D1611679466 Ack=3D1 Win=3D36864 Len=3D65480 > 1065 0.007334 192.168.122.1 =E2=86=92 192.168.122.198 TCP 65534 34482 = =E2=86=92 5201 [ACK] Seq=3D1611744946 Ack=3D1 Win=3D36864 Len=3D65480 > 1066 0.005104 192.168.122.1 =E2=86=92 192.168.122.198 TCP 56382 [TCP W= indow Full] 34482 =E2=86=92 5201 [ACK] Seq=3D1611810426 Ack=3D1 Win=3D36864= Len=3D56328 > 1067 0.015226 192.168.122.198 =E2=86=92 192.168.122.1 TCP 54 [TCP Zero= Window] 5201 =E2=86=92 34482 [ACK] Seq=3D1 Ack=3D1611090146 Win=3D0 Len=3D0 > 1068 6.298138 fe80::44b3:f5ff:fe86:c529 =E2=86=92 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 { 106= 9 .. 1070 }' > 1069 8.709313 192.168.122.1 =E2=86=92 192.168.122.198 TCP 55 34466 =E2= =86=92 5201 [ACK] Seq=3D166 Ack=3D5 Win=3D36864 Len=3D1 > 1070 0.008943 192.168.122.198 =E2=86=92 192.168.122.1 TCP 54 5201 =E2= =86=92 34482 [FIN, ACK] Seq=3D1 Ack=3D1611090146 Win=3D778240 Len=3D0 > > 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. I remembered last time it really also took me some time to totally follow. Packetdrill should be helpful :) As to the patch itself, I agreed with this fix last time while now I have to re-read that long analysis to recall as much as possible. I'm not that sure if it's a bug belonging to the Linux kernel. The other side not sending a window probe causes this issue...? The other part of me says we cannot break the user's behaviour. One way or another, I will also take a look at it again. Thanks, Jason