netdev - Re: [TEST] Wiki / instructions

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]

Date: Wed, 7 Feb 2024 07:21:59 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Matthieu Baerts <matttbe@...nel.org>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "netdev-driver-reviewers@...r.kernel.org"
 <netdev-driver-reviewers@...r.kernel.org>
Subject: Re: [TEST] Wiki / instructions

On Wed, 7 Feb 2024 09:50:48 +0100 Matthieu Baerts wrote:
> On 07/02/2024 02:37, Jakub Kicinski wrote:
> > On Mon, 5 Feb 2024 18:21:56 +0100 Matthieu Baerts wrote:  
> >> Thank you for this wiki page, and all the work with the CI infrastructure!
> >>
> >> For the debug options, I see that you are using:
> >>
> >>   kernel/configs/x86_debug.config
> >>
> >> It looks like this is specific for the 'tip' tree:
> >>
> >>   Debugging options for tip tree testing
> >>
> >> I don't know if it is still maintained, e.g. it includes DEBUG_SLAB
> >> option. But also, it enables options that are maybe not needed: GCOV?
> >> X86_DEBUG_FPU?
> >> Maybe it is better not to use this .config file, no?  
> > 
> > I haven't looked to closely. I noticed that the basic debug config
> > doesn't enable LOCKDEP ?! so I put the x86 one on top.  
> 
> I was surprised not to see LOCKDEP there, but in fact, it is: it enables
> PROVE_LOCKING, which selects LOCKDEP and a few other DEBUG_xxx ones.
> 
> So maybe it is not needed to include the x86 one?

I'm confused. Now doing:

  make O=built_test defconfig
  make O=built_test debug.config

I don't get KASAN but I get LOCKDEP :S Bleh, maybe because of the
options vng throws in?

> > I added a local patch to cut out all the obviously pointless stuff from
> > x86_debug.config  
> 
> Thank you!
> 
> > we should probably start our own config for networking
> > at some stage.  
> 
> Good idea!
> 
> On our side, we always enable DEBUG_NET, and the "debug" environment
> also has NET_NS_REFCNT_TRACKER. We should probably enable
> NET_DEV_REFCNT_TRACKER too.
> 
> Do you want me to add a new file in "kernel/configs" for net including
> these 3 options?

Just the three? What about KASAN, OBJECT debug, DEBUG_VM etc?
As much as we can without going over the 3h limit in the tests :)

> Not directly related to "Net", we also enable DEBUG_INFO (+ compressed)
> everywhere

We have debug_info, maybe vng adds it..

> + KFENCE in the "non-debug" env only,

We could do KFENCE I guess. I'm a bit surprised it's not on by default
for x86. My first choice would be to try to change that..

> disable RETPOLINE (+
> mitigations=off) not to slow down the tests in already slow envs, and
> disable a few components we don't need to accelerate the build and boot:

RETPOLINE we could kill, agreed

> DRM, SOUND, etc.
> 
> https://github.com/multipath-tcp/mptcp-upstream-virtme-docker/blob/latest/entrypoint.sh#L284

Yes, vng also adds some stuff we don't need in this area :(

> It is also possible to add some kconfig in the selftests if preferred,
> e.g. in
> 
>   ./tools/testing/selftests/net/debug.config

Would be great if everyone didn't have to go thru this exercise.
How about we start sending patches to kernel/configs/debug.config
and see if anyone screams at us?

> >> For our CI validating MPTCP tests in a "debug" mode, we use
> >> "debug.config" without "x86_debug.config". On top of that, we also
> >> disable "SLUB_DEBUG_ON", because the impact on the perf is too
> >> important, especially with slow environments. We think it is not worth
> >> it for our case. You don't have the same hardware, but if you have perf
> >> issues, don't hesitate to do the same ;)  
> > 
> > The mptcp tests take <60min to run with debug enabled, and just 
> > a single thread / VM. I think that's fine for now. But thanks for 
> > the heads up that SLUB_DEBUG_ON is problematic, for it may matter for
> > forwarding or net tests.  
> 
> The longest MPTCP selftest is currently stopped after 30 minutes due to
> the selftest timeout. I will see what we can do. That's not just because
> of SLUB_DEBUG_ON, that's normal to be very slow in such particular env.

I'll 2x the timeouts before reporting debug to patchwork, so don't
worry about it, yet.