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] [day] [month] [year] [list]
Message-ID: <CAJwJo6a4tEh2kX6dppyCWFrv3KwtaUkQBPK8uHFTqTsaweEJqg@mail.gmail.com>
Date: Wed, 7 Aug 2024 01:42:49 +0100
From: Dmitry Safonov <0x7f454c46@...il.com>
To: Simon Horman <horms@...nel.org>
Cc: Dmitry Safonov via B4 Relay <devnull+0x7f454c46.gmail.com@...nel.org>, 
	"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
Subject: Re: [PATCH net-next v2 6/7] selftests/net: Synchronize client/server
 before counters checks

On Sun, 4 Aug 2024 at 10:47, Simon Horman <horms@...nel.org> wrote:
>
> 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?

Sure, didn't intend to break someone parsing the tag, heh.

> > > # 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>
>
> ...


Thanks,
             Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ