Re: [ANN] net-next is OPEN

Re: [ANN] net-next is OPEN

[Jakub Kicinski]

On Tue, 23 Jan 2024 10:55:09 +0100 Petr Machata wrote:
> > If you authored any net or drivers/net selftests, please look around
> > and see if they are passing. If not - send patches or LMK what I need
> > to do to make them pass on the runner.. Make sure to scroll down to 
> > the "Not reporting to patchwork" section.  
> 
> A whole bunch of them fail because of no IPv6 support in the runner
> kernel. E.g. this from bridge-mdb.sh[0]:

Thanks a lot for investigating! I take it that you're looking at
forwarding? Please send a patch to add the missing configs to

tools/testing/selftests/net/forwarding/config

The runner uses that to configure the kernel on top of defconfig.

Unless I'm doing it wrong and the sub-directories are supposed to
inherit the parent directory's config? So net/forwarding/ should
be built with net/'s config? I could not find the info in docs,
does anyone know?

Re: [ANN] net-next is OPEN

[Petr Machata]

Jakub Kicinski <kuba@kernel.org> writes:

> On Tue, 23 Jan 2024 10:55:09 +0100 Petr Machata wrote:
>> > If you authored any net or drivers/net selftests, please look around
>> > and see if they are passing. If not - send patches or LMK what I need
>> > to do to make them pass on the runner.. Make sure to scroll down to 
>> > the "Not reporting to patchwork" section.  
>> 
>> A whole bunch of them fail because of no IPv6 support in the runner
>> kernel. E.g. this from bridge-mdb.sh[0]:
>
> Thanks a lot for investigating! I take it that you're looking at
> forwarding? Please send a patch to add the missing configs to
>
> tools/testing/selftests/net/forwarding/config

OK.

> The runner uses that to configure the kernel on top of defconfig.
>
> Unless I'm doing it wrong and the sub-directories are supposed to
> inherit the parent directory's config? So net/forwarding/ should
> be built with net/'s config? I could not find the info in docs,
> does anyone know?

I don't think they are, net/config defines CONFIG_VXLAN, but then the
vxlan tests still complain about unknown device type. Though maybe
there's another device type that it's missing...

What do I do to feed the config file to some build script to get a
kernel image to test? I can of course just do something like
cat config | xargs -n1 scripts/config -m, but I expect there's some
automation for it and I just can't find it.

Re: [ANN] net-next is OPEN

[Jakub Kicinski]

On Tue, 23 Jan 2024 18:04:19 +0100 Petr Machata wrote:
> > Unless I'm doing it wrong and the sub-directories are supposed to
> > inherit the parent directory's config? So net/forwarding/ should
> > be built with net/'s config? I could not find the info in docs,
> > does anyone know?  
> 
> I don't think they are, net/config defines CONFIG_VXLAN, but then the
> vxlan tests still complain about unknown device type. Though maybe
> there's another device type that it's missing...
> 
> What do I do to feed the config file to some build script to get a
> kernel image to test? I can of course just do something like
> cat config | xargs -n1 scripts/config -m, but I expect there's some
> automation for it and I just can't find it.

The CI script is based on virtme-ng. So it does this:

# $target is net or net/forwarding or drivers/net/bonding etc.
make mrproper
vng -v -b -f tools/testing/selftests/$target
# build the scripts
make headers
make -C tools/testing/selftests/$target

vng -v -r arch/x86/boot/bzImage --user root
# inside the VM
make -C tools/testing/selftests TARGETS=$target run_tests

https://github.com/kuba-moo/nipa/blob/master/contest/remote/vmksft.py#L138

You're right, it definitely does not "inherit" net's config when
running forwarding/net. I can easily make it do so, but I'm not clear
what the expectation from the kselftest subsystem is. Because if other
testers (people testing stable, KernelCI etc. et.c) don't "inherit" we
better fill in the config completely so that the tests pass for
everyone.

Re: [ANN] net-next is OPEN

[Petr Machata]

Jakub Kicinski <kuba@kernel.org> writes:

> On Tue, 23 Jan 2024 18:04:19 +0100 Petr Machata wrote:
>> > Unless I'm doing it wrong and the sub-directories are supposed to
>> > inherit the parent directory's config? So net/forwarding/ should
>> > be built with net/'s config? I could not find the info in docs,
>> > does anyone know?  
>> 
>> I don't think they are, net/config defines CONFIG_VXLAN, but then the
>> vxlan tests still complain about unknown device type. Though maybe
>> there's another device type that it's missing...
>> 
>> What do I do to feed the config file to some build script to get a
>> kernel image to test? I can of course just do something like
>> cat config | xargs -n1 scripts/config -m, but I expect there's some
>> automation for it and I just can't find it.
>
> The CI script is based on virtme-ng. So it does this:
>
> # $target is net or net/forwarding or drivers/net/bonding etc.
> make mrproper
> vng -v -b -f tools/testing/selftests/$target

Actually:

# vng -v -b -f tools/testing/selftests/${target}/config

Didn't know about vng, it's way cool!
(Despite having used virtme for a long time.)

> # build the scripts
> make headers
> make -C tools/testing/selftests/$target
>
> vng -v -r arch/x86/boot/bzImage --user root
> # inside the VM
> make -C tools/testing/selftests TARGETS=$target run_tests

I'm working my way through the selftests.

> https://github.com/kuba-moo/nipa/blob/master/contest/remote/vmksft.py#L138
>
> You're right, it definitely does not "inherit" net's config when
> running forwarding/net. I can easily make it do so, but I'm not clear
>
> what the expectation from the kselftest subsystem is. Because if other
> testers (people testing stable, KernelCI etc. et.c) don't "inherit" we
> better fill in the config completely so that the tests pass for
> everyone.

Oh, gotcha, the question was not whether it does, but whether it's
supposed to. OK.

IMHO not necessarily. net/config is for net/*.sh, net/forwarding/config
for net/forwarding/*.sh. It's not a given that whatever is needed for
net/ is needed for net/forwarding/ as well.

It will also lead to simpler patches, where enabling config options in
X/ doesn't imply checking for newly useless duplicities in X's child
directories.