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] [day] [month] [year] [list]

Message-ID: <retdlwpwrggmkm4fhqxp4gsfyz44ym656ymy42ulgsxqbs5m3o@j4p4xpsyokgl>
Date: Thu, 4 Sep 2025 01:13:42 -0700
From: Breno Leitao <leitao@...ian.org>
To: Jakub Kicinski <kuba@...nel.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 Wed, Sep 03, 2025 at 05:37:46PM -0700, Jakub Kicinski wrote:

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

Oh, I remember I read somewhere that new tests usually go to net-next,
and the fix goes to `net`

That is why I split them. In fact, the tests showed up earlier, when
i was moving the target_list in netconsole to be RCU safe.

> Regarding the test, I think it makes sense. Tho is there a way we can
> reuse more of the existing code?

Maybe. The only part that is similar is inner core (4 lines)
create_and_delete_random_target() that I could reuse if I rework the
other tests and the library.

Basically creating a new function that would do the following on an argument
(instead of NETCONS_PATH):

          echo "${DSTIP}" > "${NETCONS_PATH}"/remote_ip
          echo "${SRCIP}" > "${NETCONS_PATH}"/local_ip
          echo "${DSTMAC}" > "${NETCONS_PATH}"/remote_mac
          echo "${SRCIF}" > "${NETCONS_PATH}"/dev_name

Then reuse it in create_dynamic_target() and create_and_delete_random_target().

Initially I didn't think it was worth it, but, I can spend more time on it, and
see how it looks like.

> Do you write all these scripts by hand > or get AI to write them?

100% handcrafted test, very unfortunately. I've created the selftest to test my
changes to test some RCU changes I am going to propose to netconsole, when I
ran it, I got the memleak issue.

> I was hoping you'd add more tests relating to bonding.

I am happy to do so, given I want to get closer to netpoll. I will not be able
to do it right now due to lack of bonding knowledge, but, I will add it to my
TODO list.

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

Tell me more about this possible code path. I can focus my this initial
selftest to exercise it. 

Thanks for the review. I will send a v2 with more core utilization and then we
check which version is better.

--breno