From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DwKPhAiO; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 7873B5A027B for ; Mon, 01 Sep 2025 23:02:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1756760547; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qRkUV0EkdJ3DFyP+l5UY9XzcEOQxgftVcUqRCly2c0w=; b=DwKPhAiOB5Y16B4fAIcmYlWxFIwH/Uwd7S4AjcUt2oqGnSo8qHZDU7KySE6dcG3WdGeIcK cIfDeRPJUK6tUJjPKLw/kr4lMu4qOIWEPhtTJ6xbvMKVUCqgYOJzh92EtVMBpnPpnlA0gK pmzF06GnLzFJu+Rkf00bp4vF3ymU5dM= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-172-2mHH_OU6Oa-ZvDxP3OiIww-1; Mon, 01 Sep 2025 17:02:26 -0400 X-MC-Unique: 2mHH_OU6Oa-ZvDxP3OiIww-1 X-Mimecast-MFC-AGG-ID: 2mHH_OU6Oa-ZvDxP3OiIww_1756760545 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-45b9635bcc7so610605e9.2 for ; Mon, 01 Sep 2025 14:02:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756760545; x=1757365345; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=qRkUV0EkdJ3DFyP+l5UY9XzcEOQxgftVcUqRCly2c0w=; b=SPil8BBQM6rq6p416ROtSCtzC4eoGP8L5Neou0n1+L3EZPiWoDT8QcivaPLaaPa2W9 ahhUQURjnFyie0QEqtHINX6iQrEdC8w1j6fVF60kRvcCYNe2JjMb88I1hYEmpetOJ0ZW Tojjscmru309p37uWW67e7D3A6jE22d0dpsKH4z7af2A1MoEzphSVA8yQsYZ7VwfZfJK Q0PLLHlvwcJiOYQqcLmPxRRHCiQSePwN9XQkGckkBquqZRmJ2H8/4gGogFIdBtmXTEul zUPbm8cgIvmgpD0vOYWMGVqbhP4iCCl4XK+LOIzrpn7ubmEZn/bvhbW/agA6QIcIjE8M VT8A== X-Gm-Message-State: AOJu0YzFAtRvesq2N0qYv4IZRuKLddHg50PDnf8xg7rM5wKLJ6AqO++X XSeGaqykHAYi3xBpPCaLg4pBXSBWGEbQE6lBNg2yuShOPIJjvk3Fyx70LC2C9wd2LCHkQxbC0Zg k7HVLAeqbu8SZgUMnscnMFBr/eVgPxbHuVu2bqzvltlCFbUgsQrAXNg== X-Gm-Gg: ASbGnctdLNdvyF3KNEgBzXSJ9W+aIEg8xosjjv2cLZkzp74Ez0i1NSJfZB/90Sti6wV kzTNNp1fb8+I+9T94smvfKfm0URuhnhpJrVFyAmY+WQdNlu9drvbNaqBPzVGNehnuZOvJwdtjPI DE2zOdosNi4Vxdw7kyZQl7PnMdb0FejxPb8M92JuHi+df84wxw+p1CCuuk174s+frZKtQ/IH3/U fMgTUZkKGvXk/UOoW8o5rZUBRFDLCdZ0D2br3xcxOWzHN4o/U0PK2AOevYQbi7WeCDiwqdrFNh6 DxE/Y3lOiYiA9DOZvki7QXJmQaqqAMXKCMfpMUN+h2j31u3gazQ= X-Received: by 2002:a05:600c:190b:b0:45b:89ac:b7f7 with SMTP id 5b1f17b1804b1-45b89acb982mr50361545e9.33.1756760544643; Mon, 01 Sep 2025 14:02:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEbcP4S5etvfXqmjHJfHpxeBcpkX2JQAELiDTRkN/dZSvJrVxXiUB8WEsW0zdvJ9O5OMFdFJg== X-Received: by 2002:a05:600c:190b:b0:45b:89ac:b7f7 with SMTP id 5b1f17b1804b1-45b89acb982mr50361375e9.33.1756760544103; Mon, 01 Sep 2025 14:02:24 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45b7e7ef7cfsm170278545e9.6.2025.09.01.14.02.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 14:02:23 -0700 (PDT) Date: Mon, 1 Sep 2025 23:02:22 +0200 From: Stefano Brivio To: Paul Holzinger Subject: Re: [PATCH v3 0/7] tcp: Fixes for issues uncovered by tests with 6.17-rc1 kernels Message-ID: <20250901230222.2a513287@elisabeth> In-Reply-To: <37b381a1-f603-47e7-be9a-cf9ce4985b47@redhat.com> References: <20250829201132.1561650-1-sbrivio@redhat.com> <4a234ba5-90bb-40e3-b479-b65ffedc6fd7@redhat.com> <37b381a1-f603-47e7-be9a-cf9ce4985b47@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: kURa8LbDFEF54LuDFf0csczp9Y34fyPx8vUW2eUhr28_1756760545 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 5WO6JTIHCYS2NSF4TLRF2VD6RO7VT7QG X-Message-ID-Hash: 5WO6JTIHCYS2NSF4TLRF2VD6RO7VT7QG X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Jon Maloy , David Gibson 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, 1 Sep 2025 19:36:18 +0200 Paul Holzinger wrote: > On 01/09/2025 12:02, Paul Holzinger wrote: > > Hi, > > > > On 29/08/2025 22:11, Stefano Brivio wrote: =20 > >> Starting from Linux kernel commit 1d2fbaad7cd8 ("tcp: stronger > >> sk_rcvbuf checks"), window limits are enforced more aggressively with > >> a bigger amount of zero-window updates compared to what happened with > >> e2142825c120 ("net: tcp: send zero-window ACK when no memory") alone, > >> and occasional duplicate ACKs can now be seen also for local transfers > >> with default (208 KiB) socket buffer sizes. > >> > >> Paul reports that, with 6.17-rc1-ish kernels, Podman tests for the > >> pasta integration occasionally fail on the "TCP/IPv4 large transfer, > >> tap" case. > >> > >> While playing with a reproducer that seems to be matching those > >> failures: > >> > >> =C2=A0=C2=A0 while true; do ./pasta --trace -l /tmp/pasta.log -p=20 > >> /tmp/pasta.pcap --config-net -t 5555 -- socat TCP-LISTEN:5555=20 > >> OPEN:/tmp/large.rcv,trunc & (sleep 0.3; socat -T2 OPEN:large.bin=20 > >> TCP:88.198.0.164:5555; ); wait; diff large.bin /tmp/large.rcv ||=20 > >> break; done > >> > >> and a kernel including that commit, I hit a few different failures, > >> that should be fixed by this series. > >> > >> Paul tested v1 of this series and found an additional failure > >> (transfer timeout), which I could reproduce with a slightly different > >> command: > >> > >> =C2=A0=C2=A0 while true; do ./pasta --trace -l /tmp/pasta.log -p=20 > >> /tmp/pasta.pcap --config-net -t 5555 -- socat TCP-LISTEN:5555=20 > >> EXEC:./write.sh & (sleep 0.3; socat -T2 OPEN:large.bin=20 > >> TCP:88.198.0.164:5555; ); wait; diff large.bin /tmp/large.rcv ||=20 > >> break; done > >> > >> where write.sh is simply: > >> > >> =C2=A0=C2=A0 #!/bin/sh > >> =C2=A0=C2=A0 =C2=A0=C2=A0 cat > /tmp/large.rcv > >> > >> so that the connection is not half-closed starting from the beginning, > >> because socat can't make assumptions about the unidirectional nature > >> of the traffic. This should now be fixed as well by the new version of > >> patch 3/7. > >> > >> v3: > >> =C2=A0=C2=A0 - add patch 6/7 > >> =C2=A0=C2=A0 - in 7/7, check dlen <=3D 1 for keep-alive segments, inst= ead of len=20 > >> <=3D 1 > >> > >> v2: in 3/6, rewind sequence also if the zero-window update comes in > >> =C2=A0=C2=A0=C2=A0=C2=A0 the middle of a batch with non-zero window up= dates > >> > >> Stefano Brivio (7): > >> =C2=A0=C2=A0 tcp: FIN flags have to be retransmitted as well > >> =C2=A0=C2=A0 tcp: Factor sequence rewind for retransmissions into a ne= w function > >> =C2=A0=C2=A0 tcp: Rewind sequence when guest shrinks window to zero > >> =C2=A0=C2=A0 tcp: Fix closing logic for half-closed connections > >> =C2=A0=C2=A0 tcp: Don't try to transmit right after the peer shrank th= e window to > >> =C2=A0=C2=A0=C2=A0=C2=A0 zero > >> =C2=A0=C2=A0 tcp: Cast operands of sequence comparison macros to uint3= 2_t before > >> =C2=A0=C2=A0=C2=A0=C2=A0 using them > >> =C2=A0=C2=A0 tcp: Fast re-transmit if half-closed, make TAP_FIN_RCVD p= ath > >> =C2=A0=C2=A0=C2=A0=C2=A0 consistent > >> > >> =C2=A0 tcp.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 1= 81 ++++++++++++++++++++++++++++++++++--------------- > >> =C2=A0 tcp_internal.h |=C2=A0 12 ++-- > >> =C2=A0 2 files changed, 136 insertions(+), 57 deletions(-) =20 > > I am afraid I have to give bad news that it is still broken. My=20 > > reproducer failed after 70 mins (without logs) which means it took=20 > > longer this time but I only have one run so far so hard to tell. I can= =20 > > enable logs again and see how long it takes then. =20 >=20 > Ok, my logs reproducer is running for well over 7 hours now without=20 > triggering the issue, so this series improves the situation a lot. I=20 > keep trying but I think this is more than enough to convince me that=20 > this here is good. >=20 > Tested-by: Paul Holzinger Thanks for testing and re-testing. Just one question before I go ahead and merge this: how did the original failure from earlier on Tuesday look like? Was that again a timeout? Another thing worth trying: captures without logs, which should be much less overhead (hence difference in timing). I should be able to figure out issues of this sort with captures and no logs (it's much harder the other way around). --=20 Stefano