linux-kernel - Re: [PATCH net-next] selftest: netcons: create a torture test

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: <20250903173746.5c04c306@kernel.org>
Date: Wed, 3 Sep 2025 17:37:46 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Shuah Khan <shuah@...nel.org>,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 linux-kselftest@...r.kernel.org, asantostc@...il.com, efault@....de,
 calvin@...nvd.org, kernel-team@...a.com
Subject: Re: [PATCH net-next] selftest: netcons: create a torture test

On Tue, 02 Sep 2025 09:33:33 -0700 Breno Leitao wrote:
> Create a netconsole test that puts a lot of pressure on the netconsole
> list manipulation. Do it by creating dynamic targets and deleting
> targets while messages are being sent. Also put interface down while the
> messages are being sent, as creating parallel targets.
> 
> The code launches three background jobs on distinct schedules:
> 
>  * Toggle netcons target every 30 iterations
>  * create and delete random_target every 50 iterations
>  * toggle iface every 70 iterations
> 
> This creates multiple concurrency sources that interact with netconsole
> states. This is good practice to simulate stress, and exercise netpoll
> and netconsole locks.

Oh, when you said "selftest will be posted later" in the fix I thought
you meant days, not hours later :) It's better if the fix and test are
in one series. Better for backports, and it avoid situations like last
night when the fix was already dropped from pw but this test was still
running (and crashing the kernel).

Regarding the test, I think it makes sense. Tho is there a way we can
reuse more of the existing code? Do you write all these scripts by hand
or get AI to write them? I was hoping you'd add more tests relating to
bonding. To confirm bonding still works. And as I mentioned I think
bonding is still a bit buggy if we "propagate" multiple nps and then
remove them out of order..