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: <f6437533-b0c9-422b-af00-fb8a236b1956@kernel.org>
Date: Tue, 6 Feb 2024 12:16:43 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 MPTCP Upstream <mptcp@...ts.linux.dev>, Paolo Abeni <pabeni@...hat.com>,
 Mat Martineau <martineau@...nel.org>
Subject: Re: [TEST] The no-kvm CI instances going away

Hi Jakub,

On 06/02/2024 02:41, Jakub Kicinski wrote:
> because cloud computing is expensive I'm shutting down the instances
> which were running without KVM support. We're left with the KVM-enabled
> instances only (metal) - one normal and one with debug configs enabled.

Thank you for the notification!

It sounds like good news if the non-support of KVM was causing issues :)

I think we can then no longer ignore the two MPTCP tests that were
unstable in the previous environment.

The results from the different tests running on the -dbg instances don't
look good. Maybe some debug kconfig have a too big impact? [1]

For MPTCP, one test always hits the selftest timeout [2] when using a
debug kconfig. I don't know what to do in this case: if we need to set a
timeout value that is supported by debug environments, the value will be
so high, it will no longer catch issues "early enough" in "normal"
environments.
Or could it be possible to ignore or double the timeout value in this
debug environment?

Also, what is the plan with this debug env? It looks like the results
are not reported to patchwork for the moment. Maybe only "important"
issues, like kernel warnings, could be reported? Failed tests could be
reported as "Warning" instead of "Fail"?

[1]
https://lore.kernel.org/netdev/90c6d9b6-0bc4-468a-95fe-ebc2a23fffc1@kernel.org/
[2]
https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/453502/1-mptcp-join-sh/stdout

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ