netdev - Re: [ANN] net-next is OPEN

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: <bd985576-cc99-49c5-a2e0-09622fd6027a@kernel.org>
Date: Wed, 24 Jan 2024 14:48:02 -0700
From: David Ahern <dsahern@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>, Hangbin Liu <liuhangbin@...il.com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "netdev-driver-reviewers@...r.kernel.org"
 <netdev-driver-reviewers@...r.kernel.org>
Subject: Re: [ANN] net-next is OPEN

On 1/24/24 9:59 AM, Jakub Kicinski wrote:
> On Wed, 24 Jan 2024 09:35:09 -0700 David Ahern wrote:
>>> This is the latest run:
>>>
>>> https://netdev-2.bots.linux.dev/vmksft-net-mp/results/435141/1-fcnal-test-sh/stdout
>>>
>>> the nettest warning is indeed gone, but the failures are the same:  
>>
>> yep, I will send a formal patch. I see the timeout is high enough, so
>> good there.
> 
> Well, kinda, to be honest I did bump the time to 4000s locally.
> The runtime of the entire net suite 1h 10min - that's pretty much
> the runtime of this one test :) The VMs run the tests without

one *script* = 900+ tests. :-)


> HW virtualization, so they are a bit slower, but it'd be nice
> if no local hacks were necessary. 
> 
> I haven't sent a patch to bump it because it may make more sense
> to split the test into multiple. But as a stop gap we can as well
> bump the timeout.

The script has the tests in groups and each group can be run in parallel
(with Hangbin's recent namespace changes). I can look at splitting that
script into many (or write wrappers to run specific groups), but even
then most of those test groups need more than 45 seconds. There are lot
of permutations covered (with and without vrf, different address types,
different uapis, ...).

> 
>>> $ grep FAIL stdout 
>>> # TEST: ping local, VRF bind - VRF IP                 [FAIL]
>>> # TEST: ping local, device bind - ns-A IP             [FAIL]
>>> # TEST: ping local, VRF bind - VRF IP                 [FAIL]
>>> # TEST: ping local, device bind - ns-A IP             [FAIL]
>>>
>>> :(  
>>
>> known problems. I can disable the tests for now so we avoid regressions,
>> and add to the TO-DO list for someone with time.

Sent a PR to fix a few things. I did not have to disable any tests -
everything passes cleanly with the changes. If tests fail after those
are applied, let's compare OS environments - maybe some sysctl is
enabled or disabled (or a CONFIG) in your environment.