Message ID | 20240130-tcp-ao-test-key-mgmt-v2-0-d190430a6c60@arista.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-43916-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp983554dyb; Mon, 29 Jan 2024 19:52:38 -0800 (PST) X-Google-Smtp-Source: AGHT+IHxsz8rtMP8Kk5yPHr3R02rGPjxAuRGo5Ve7Jp4nHe8SwK+SWpElK0TR1Auhz7ygPyGuJIs X-Received: by 2002:a17:906:3047:b0:a35:34c0:e1bd with SMTP id d7-20020a170906304700b00a3534c0e1bdmr4727345ejd.67.1706586757872; Mon, 29 Jan 2024 19:52:37 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706586757; cv=pass; d=google.com; s=arc-20160816; b=tTIBOZ5OOupDZBTpcjc6zpL8BkbZotMoOkN1rN7ALQkQYwIZIAZGp3p4YzlDahu8Kq yGlfFl9jC9qtYrwZq+nlymXKltv3hPKqUZ//HIpagM6HVPkp4MESMkXBUWxeoeKiQoOK SVybsgoXCvYhW9FEherljQMRxaWv1YZNSAeT4K2pZL47oZlbT9XOYTaKMjWDKndvflcJ ZmOpHwBJQHa2GYfLRyezB4KUPIhkMD1ZmfcQ4RqIx0+VXDsOotHfEPrPFTc2Kshso2HY ytq7VwmWNSoUdlvwlvbNfmLUInhW7eKbbUaewuUeSZZBjd1OEcA3wrdfn5/WWNFhWmjZ uG4Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=3IAAtpYMk4Ivb7jeyKnDj3sOOnhVdi6sq/asAwlVHv0=; fh=uuYKeLeXbqJGZoGIz60yVjwWAOb2l0qc7NtFkAbukeo=; b=HL/wjZrAF3p+agnhdrRX9MYHQuN5rOKpDQai5i3+NMgLSsrQwKw6V7+1Sjir2mTX2h 0RkGtF749a2WcDuCbFZNcSlOYXpxN8VW8aCO9PuSp3MKbbW0pZQ0ea1ou+htAvKlsSF9 iIBn82ZGGqnQuSTWu2Qn99LGuI+zFqMaa/zI5L7HxEsxm48r1z54FlaIxmTBW/HnYSQg wU3vzQYDK/GhioQM5+tV5br9YRffvj5GKGV5ze6OE/S6hYIb/HAVC41Nxwl4EE/MgPk/ BbJ+yIi6YL+hJdYlTNwHvpUtiDVHZgKeSHueko/P0wacraEX3TFQTt8wSXLQVLV4vCpG 1a0Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@arista.com header.s=google header.b=WMwvuKG7; arc=pass (i=1 spf=pass spfdomain=arista.com dkim=pass dkdomain=arista.com dmarc=pass fromdomain=arista.com); spf=pass (google.com: domain of linux-kernel+bounces-43916-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43916-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=arista.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id cw13-20020a170906c78d00b00a35edc5b26dsi910487ejb.278.2024.01.29.19.52.37 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 19:52:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-43916-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@arista.com header.s=google header.b=WMwvuKG7; arc=pass (i=1 spf=pass spfdomain=arista.com dkim=pass dkdomain=arista.com dmarc=pass fromdomain=arista.com); spf=pass (google.com: domain of linux-kernel+bounces-43916-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43916-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=arista.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 7FECD1F263FC for <ouuuleilei@gmail.com>; Tue, 30 Jan 2024 03:52:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D03D538387; Tue, 30 Jan 2024 03:52:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arista.com header.i=@arista.com header.b="WMwvuKG7" Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5CC16374D4 for <linux-kernel@vger.kernel.org>; Tue, 30 Jan 2024 03:52:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706586723; cv=none; b=iI8lJ7NvexDAume/f99+XP3A23qgj5UfpD5aq5opUwpBry0AnBmeNDr4mYDpq2eYcTLY/wm3yh4KS0g9pC18CLoLnCQ+dsmskZqbQWZkzQJoR1gT1DPpFUnObTeWEu1qygf+KCgBufR4mV9hNddCOD4PDyVlYCPXd6fQr4qMQK8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706586723; c=relaxed/simple; bh=mrSUsYr40vZLSd08HCa9ghUj2kZmeOFNxhdsAlHKBFc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=RK04/f3pc/+tRN16yoxohk7EVlHPBhXwWy3fgQ+ZDvZTV/r5ViSN+aPsMHnVU31NKnRyD2oWvmWBID0rLKilcY+7cbSChk+wO1J4XO3i7iwMLxTFW4xQkwIgF/9hNedDFub5ykSR6axN66bjUXYkAXyYHLThnfIzPQyCPOk8/Tk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=arista.com; spf=pass smtp.mailfrom=arista.com; dkim=pass (2048-bit key) header.d=arista.com header.i=@arista.com header.b=WMwvuKG7; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=arista.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arista.com Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-337d05b8942so3041614f8f.3 for <linux-kernel@vger.kernel.org>; Mon, 29 Jan 2024 19:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; t=1706586719; x=1707191519; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=3IAAtpYMk4Ivb7jeyKnDj3sOOnhVdi6sq/asAwlVHv0=; b=WMwvuKG7/TZq0DtcrOUKeNIi/YzL8SAR6/eYBRfInMYk35qTUihSVGabsN2y8Yqw82 NdteorllG884xr66l8dkAf7qE/tu/rsBga+UiSlwDNGYQeTXJaPzPaicO1AbdCFu3j/A G5MnoTCR+AlsHVal7nK4jOa46AqfEJNvOc0Zzn1BRPzU96Pxk0DXH+aq7ynH1wbtHqCX VUuRuNyZsp0a23q4hZ9h5NriLK/OTFPo/f936MvWbxZojeTX47Rq3Z3rRDWnEnbdMna3 Dvtx+NKuJAed/WsZunwNuZImE6YV9WwU++lhlM+Hn4JOuOqtGfbTThuQr839DC/wHQfi Ohuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706586719; x=1707191519; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3IAAtpYMk4Ivb7jeyKnDj3sOOnhVdi6sq/asAwlVHv0=; b=MiuRDJssWEUz9+BcueYs96GcnSvXjulzqPf4MXlpvN9yeB8YiysgMNp2n6EffguFPU e5y/1T29qHTOEix4srJuZhwX7LiOwcd3TKkaGxjA1IG9Lu8vsNw68SBaYfPvePncrglQ WVXiqLNo/cJiLjICnoLni2/CNk877AuSmaXaAm/4twxpO4w2EBTlPR76we/ZiOyG4v78 aUKnWNc7D+qLzdMW+mc5qv/uhKNA86Jh2cRorSvCy2JkD0SvvNFsp0NxJOHrY+mwtR+e VGAMx2+FgRm+8wUTt6ouK0d69sXvK+n8EG/eBWceUopx/Eged11qyl78s55Oli5n4tf+ WTvQ== X-Gm-Message-State: AOJu0YzreH2pVFkN7HbsUAixS98BN3wOtrAIValDSOX/BV8fFYSslWT8 KN9QNnWfroRmNPtb8QZa+551yb/u2KCusAyVRe7Nm9C/BsVOy7qK9PrH7OEcBw== X-Received: by 2002:a05:6000:2c8:b0:33a:f521:7062 with SMTP id o8-20020a05600002c800b0033af5217062mr1762641wry.3.1706586719581; Mon, 29 Jan 2024 19:51:59 -0800 (PST) Received: from Mindolluin.ire.aristanetworks.com ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id ay13-20020a5d6f0d000000b00337d6aa3912sm9513207wrb.10.2024.01.29.19.51.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 19:51:58 -0800 (PST) From: Dmitry Safonov <dima@arista.com> To: "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>, Dmitry Safonov <0x7f454c46@gmail.com> Cc: Dmitry Safonov <dima@arista.com>, Mohammad Nassiri <mnassiri@ciena.com>, Simon Horman <horms@kernel.org>, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 0/3] selftests/net: A couple of typos fixes in key-management/rst tests Date: Tue, 30 Jan 2024 03:51:51 +0000 Message-ID: <20240130-tcp-ao-test-key-mgmt-v2-0-d190430a6c60@arista.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: b4 0.13-dev-b6b4b X-Developer-Signature: v=1; a=ed25519-sha256; t=1706586711; l=1089; i=dima@arista.com; s=20231212; h=from:subject:message-id; bh=mrSUsYr40vZLSd08HCa9ghUj2kZmeOFNxhdsAlHKBFc=; b=neGs9rbOA+EqGzLfMqyu3VFWcABDrXh0tWgdIRGzuXY3D1GWlihFguJm9kCKBjjMSM9vWnxAZ xt7XFjrr9fKA0St+JyMBuYUlSkQFRgyc0lvx0z3G+8M10EKps+dqft3 X-Developer-Key: i=dima@arista.com; a=ed25519; pk=hXINUhX25b0D/zWBKvd6zkvH7W2rcwh/CH6cjEa3OTk= Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789485916368759221 X-GMAIL-MSGID: 1789485916368759221 |
Series |
selftests/net: A couple of typos fixes in key-management/rst tests
|
|
Message
Dmitry Safonov
Jan. 30, 2024, 3:51 a.m. UTC
Changes in v2:
- Dropped "selftests/net: Clean-up double assignment", going to send it
to net-next with other changes (Simon)
- Added a patch to rectify RST selftests.
- Link to v1: https://lore.kernel.org/r/20240118-tcp-ao-test-key-mgmt-v1-0-3583ca147113@arista.com
Two typo fixes, noticed by Mohammad's review.
And a fix for an issue that got uncovered.
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
Dmitry Safonov (2):
selftests/net: Rectify key counters checks
selftests/net: Repair RST passive reset selftest
Mohammad Nassiri (1):
selftests/net: Argument value mismatch when calling verify_counters()
.../testing/selftests/net/tcp_ao/key-management.c | 46 ++++---
tools/testing/selftests/net/tcp_ao/lib/sock.c | 12 +-
tools/testing/selftests/net/tcp_ao/rst.c | 138 ++++++++++++++-------
3 files changed, 124 insertions(+), 72 deletions(-)
---
base-commit: ecb1b8288dc7ccbdcb3b9df005fa1c0e0c0388a7
change-id: 20240118-tcp-ao-test-key-mgmt-bb51a5fe15a2
Best regards,
Comments
On Tue, 30 Jan 2024 03:51:51 +0000 Dmitry Safonov wrote: > Two typo fixes, noticed by Mohammad's review. > And a fix for an issue that got uncovered. I can confirm that all tests pass now :) Thank you!
Hello: This series was applied to netdev/net.git (main) by Jakub Kicinski <kuba@kernel.org>: On Tue, 30 Jan 2024 03:51:51 +0000 you wrote: > Changes in v2: > - Dropped "selftests/net: Clean-up double assignment", going to send it > to net-next with other changes (Simon) > - Added a patch to rectify RST selftests. > - Link to v1: https://lore.kernel.org/r/20240118-tcp-ao-test-key-mgmt-v1-0-3583ca147113@arista.com > > Two typo fixes, noticed by Mohammad's review. > And a fix for an issue that got uncovered. > > [...] Here is the summary with links: - [v2,1/3] selftests/net: Argument value mismatch when calling verify_counters() https://git.kernel.org/netdev/net/c/d8f5df1fcea5 - [v2,2/3] selftests/net: Rectify key counters checks https://git.kernel.org/netdev/net/c/384aa16d3776 - [v2,3/3] selftests/net: Repair RST passive reset selftest https://git.kernel.org/netdev/net/c/6caf3adcc877 You are awesome, thank you!
On 2/1/24 00:36, Jakub Kicinski wrote: > On Tue, 30 Jan 2024 03:51:51 +0000 Dmitry Safonov wrote: >> Two typo fixes, noticed by Mohammad's review. >> And a fix for an issue that got uncovered. > > I can confirm that all tests pass now :) > Thank you! Thanks Jakub! Please, let me know if there will be other issues with tcp-ao tests :) Going to work on tracepoints and some other TCP-AO stuff for net-next. Thanks, Dmitry
On Thu, 1 Feb 2024 00:50:46 +0000 Dmitry Safonov wrote: > Please, let me know if there will be other issues with tcp-ao tests :) > > Going to work on tracepoints and some other TCP-AO stuff for net-next. Since you're being nice and helpful I figured I'll try testing TCP-AO with debug options enabled :) (kernel/configs/debug.config and kernel/configs/x86_debug.config included), that slows things down and causes a bit of flakiness in unsigned-md5-* tests: https://netdev.bots.linux.dev/flakes.html?br-cnt=75&tn-needle=tcp-ao This has links to outputs: https://netdev.bots.linux.dev/contest.html?executor=vmksft-tcp-ao-dbg&pass=0 If it's a timing thing - FWIW we started exporting KSFT_MACHINE_SLOW=yes on the slow runners.
Hi Jakub, On 2/1/24 21:21, Jakub Kicinski wrote: > On Thu, 1 Feb 2024 00:50:46 +0000 Dmitry Safonov wrote: >> Please, let me know if there will be other issues with tcp-ao tests :) >> >> Going to work on tracepoints and some other TCP-AO stuff for net-next. > > Since you're being nice and helpful I figured I'll try testing TCP-AO > with debug options enabled :) (kernel/configs/debug.config and > kernel/configs/x86_debug.config included), Haha :) > that slows things down > and causes a bit of flakiness in unsigned-md5-* tests: > > https://netdev.bots.linux.dev/flakes.html?br-cnt=75&tn-needle=tcp-ao > > This has links to outputs: > https://netdev.bots.linux.dev/contest.html?executor=vmksft-tcp-ao-dbg&pass=0 > > If it's a timing thing - FWIW we started exporting > KSFT_MACHINE_SLOW=yes on the slow runners. I think, I know what happens here: # ok 8 AO server (AO_REQUIRED): AO client: counter TCPAOGood increased 4 => 6 # ok 9 AO server (AO_REQUIRED): unsigned client # ok 10 AO server (AO_REQUIRED): unsigned client: counter TCPAORequired increased 1 => 2 # not ok 11 AO server (AO_REQUIRED): unsigned client: Counter netns_ao_good was not expected to increase 7 => 8 for each of tests the server listens at a new port, but re-uses the same namespaces+veth. If the node/machine is quite slow, I guess a segment might have been retransmitted and the test that initiated it had already finished. And as result, the per-namespace counters are incremented, which makes the test fail (IOW, the test expects all segments in ns being dropped). So, I should do one of the options: 1. relax per-namespace checks (the per-socket and per-key counters are checked) 2. unshare(net) + veth setup for each test 3. split the selftest on smaller ones (as they create new net-ns in initialization) I'd probably prefer (2), albeit it slows down that slow machine even more, but I don't think creating 2 net-ns + veth pair per each test would add a lot more overhead even on some rpi board. But let's see, maybe I'll just go with (1) as that's really easy. I'll cook a patch this week. Thanks, Dmitry
On 2/1/24 22:25, Dmitry Safonov wrote: > Hi Jakub, > > On 2/1/24 21:21, Jakub Kicinski wrote: >> On Thu, 1 Feb 2024 00:50:46 +0000 Dmitry Safonov wrote: >>> Please, let me know if there will be other issues with tcp-ao tests :) >>> >>> Going to work on tracepoints and some other TCP-AO stuff for net-next. >> >> Since you're being nice and helpful I figured I'll try testing TCP-AO >> with debug options enabled :) (kernel/configs/debug.config and >> kernel/configs/x86_debug.config included), > > Haha :) > >> that slows things down >> and causes a bit of flakiness in unsigned-md5-* tests: >> >> https://netdev.bots.linux.dev/flakes.html?br-cnt=75&tn-needle=tcp-ao >> >> This has links to outputs: >> https://netdev.bots.linux.dev/contest.html?executor=vmksft-tcp-ao-dbg&pass=0 >> >> If it's a timing thing - FWIW we started exporting >> KSFT_MACHINE_SLOW=yes on the slow runners. > > I think, I know what happens here: > > # ok 8 AO server (AO_REQUIRED): AO client: counter TCPAOGood increased 4 > => 6 > # ok 9 AO server (AO_REQUIRED): unsigned client > # ok 10 AO server (AO_REQUIRED): unsigned client: counter TCPAORequired > increased 1 => 2 > # not ok 11 AO server (AO_REQUIRED): unsigned client: Counter > netns_ao_good was not expected to increase 7 => 8 > > for each of tests the server listens at a new port, but re-uses the same > namespaces+veth. If the node/machine is quite slow, I guess a segment > might have been retransmitted and the test that initiated it had already > finished. > And as result, the per-namespace counters are incremented, which makes > the test fail (IOW, the test expects all segments in ns being dropped). > > So, I should do one of the options: > > 1. relax per-namespace checks (the per-socket and per-key counters are > checked) > 2. unshare(net) + veth setup for each test > 3. split the selftest on smaller ones (as they create new net-ns in > initialization) Actually, I think there may be an easier fix: 4. Make sure that client close()s TCP-AO first, making it twsk. And also make sure that net-ns counters read post server's close(). Will do this, let's see if this fixes the flakiness on the netdev bot :) > I'd probably prefer (2), albeit it slows down that slow machine even > more, but I don't think creating 2 net-ns + veth pair per each test > would add a lot more overhead even on some rpi board. But let's see, > maybe I'll just go with (1) as that's really easy. > > I'll cook a patch this week. Thanks, Dmitry
On 2/1/24 23:37, Dmitry Safonov wrote: > On 2/1/24 22:25, Dmitry Safonov wrote: >> Hi Jakub, >> >> On 2/1/24 21:21, Jakub Kicinski wrote: >>> On Thu, 1 Feb 2024 00:50:46 +0000 Dmitry Safonov wrote: >>>> Please, let me know if there will be other issues with tcp-ao tests :) >>>> >>>> Going to work on tracepoints and some other TCP-AO stuff for net-next. >>> >>> Since you're being nice and helpful I figured I'll try testing TCP-AO >>> with debug options enabled :) (kernel/configs/debug.config and >>> kernel/configs/x86_debug.config included), >> >> Haha :) >> >>> that slows things down >>> and causes a bit of flakiness in unsigned-md5-* tests: >>> >>> https://netdev.bots.linux.dev/flakes.html?br-cnt=75&tn-needle=tcp-ao >>> >>> This has links to outputs: >>> https://netdev.bots.linux.dev/contest.html?executor=vmksft-tcp-ao-dbg&pass=0 >>> >>> If it's a timing thing - FWIW we started exporting >>> KSFT_MACHINE_SLOW=yes on the slow runners. >> >> I think, I know what happens here: >> >> # ok 8 AO server (AO_REQUIRED): AO client: counter TCPAOGood increased 4 >> => 6 >> # ok 9 AO server (AO_REQUIRED): unsigned client >> # ok 10 AO server (AO_REQUIRED): unsigned client: counter TCPAORequired >> increased 1 => 2 >> # not ok 11 AO server (AO_REQUIRED): unsigned client: Counter >> netns_ao_good was not expected to increase 7 => 8 >> >> for each of tests the server listens at a new port, but re-uses the same >> namespaces+veth. If the node/machine is quite slow, I guess a segment >> might have been retransmitted and the test that initiated it had already >> finished. >> And as result, the per-namespace counters are incremented, which makes >> the test fail (IOW, the test expects all segments in ns being dropped). >> >> So, I should do one of the options: >> >> 1. relax per-namespace checks (the per-socket and per-key counters are >> checked) >> 2. unshare(net) + veth setup for each test >> 3. split the selftest on smaller ones (as they create new net-ns in >> initialization) > > Actually, I think there may be an easier fix: > > 4. Make sure that client close()s TCP-AO first, making it twsk. > And also make sure that net-ns counters read post server's close(). > > Will do this, let's see if this fixes the flakiness on the netdev bot :) FWIW, I ended up with this: https://lore.kernel.org/all/20240202-unsigned-md5-netns-counters-v1-1-8b90c37c0566@arista.com/ I reproduced the issue once, running unsigned-md5* in a loop, while in another terminal building linux-next with all cores. With the patch above, it survived 77 iterations of both ipv4/ipv6 tests so far. So, there is a chance it fixes the issue :) Thanks, Dmitry
On Fri, 2 Feb 2024 02:30:52 +0000 Dmitry Safonov wrote: > > Actually, I think there may be an easier fix: > > > > 4. Make sure that client close()s TCP-AO first, making it twsk. > > And also make sure that net-ns counters read post server's close(). > > > > Will do this, let's see if this fixes the flakiness on the netdev bot :) > > FWIW, I ended up with this: > https://lore.kernel.org/all/20240202-unsigned-md5-netns-counters-v1-1-8b90c37c0566@arista.com/ > > I reproduced the issue once, running unsigned-md5* in a loop, while in > another terminal building linux-next with all cores. > With the patch above, it survived 77 iterations of both ipv4/ipv6 tests > so far. So, there is a chance it fixes the issue :) That was quick! Fingers crossed :)