linux-kernel - Re: [PATCH net-next v2 6/7] selftests/net: Synchronize client/server before counters checks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240804094751.GH2504122@kernel.org>
Date: Sun, 4 Aug 2024 10:47:51 +0100
From: Simon Horman <horms@...nel.org>
To: Dmitry Safonov via B4 Relay <devnull+0x7f454c46.gmail.com@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Shuah Khan <shuah@...nel.org>,
	Mohammad Nassiri <mnassiri@...na.com>, netdev@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
	Dmitry Safonov <0x7f454c46@...il.com>
Subject: Re: [PATCH net-next v2 6/7] selftests/net: Synchronize client/server
 before counters checks

On Fri, Aug 02, 2024 at 10:23:30AM +0100, Dmitry Safonov via B4 Relay wrote:
> From: Dmitry Safonov <0x7f454c46@...il.com>
> 
> On tests that are expecting failure the timeout value is
> TEST_RETRANSMIT_SEC == 1 second. Which is big enough for most of devices
> under tests. But on a particularly slow machine/VM, 1 second might be
> not enough for another thread to be scheduled and attempt to connect().
> It is not a problem for tests that expect connect() to succeed as
> the timeout value for them (TEST_TIMEOUT_SEC) is intentionally bigger.
> 
> One obvious way to solve this would be to increase TEST_RETRANSMIT_SEC.
> But as all tests would increase the timeouts, that's going to sum up.
> 
> But here is less obvious way that keeps timeouts for expected connect()
> failures low: just synchronize the two threads, which will assure that
> before counter checks the other thread got a chance to run and timeout
> on connect(). The expected increase of the related counter for listen()
> socket will yet test the expected failure.
> 
> Never happens on my machine, but I suppose the majority of netdev's
> connect-deny-* flakes [1] are caused by this.
> 
> Fixes:

Hi Dmitry,

I realise it probably wasn't intended to be a fixes tag,
but it turns out to be an invalid one. Could you express this
in a different way?

> > # selftests: net/tcp_ao: connect-deny_ipv6
> > # 1..21
> > # # 462[lib/setup.c:243] rand seed 1720905426
> > # TAP version 13
> > # ok 1 Non-AO server + AO client
> > # not ok 2 Non-AO server + AO client: TCPAOKeyNotFound counter did not increase: 0 <= 0
> > # ok 3 AO server + Non-AO client
> > # ok 4 AO server + Non-AO client: counter TCPAORequired increased 0 => 1
> ...
> 
> [1]: https://netdev-3.bots.linux.dev/vmksft-tcp-ao/results/681741/6-connect-deny-ipv6/stdout
> Signed-off-by: Dmitry Safonov <0x7f454c46@...il.com>

...