netdev - Re: [PATCH v2 net-next 0/7] selftests: net: Switch pmtu.sh to use the internal ovs script.

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: Tue, 25 Jun 2024 10:27:03 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Aaron Conole <aconole@...hat.com>, Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, dev@...nvswitch.org, 
 linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org, Pravin B
 Shelar <pshelar@....org>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Shuah Khan <shuah@...nel.org>, Stefano
 Brivio <sbrivio@...hat.com>, Adrián Moreno
 <amorenoz@...hat.com>,  Simon Horman <horms@...nel.org>
Subject: Re: [PATCH v2 net-next 0/7] selftests: net: Switch pmtu.sh to use
 the internal ovs script.

On Mon, 2024-06-24 at 12:53 -0400, Aaron Conole wrote:
> Aaron Conole <aconole@...hat.com> writes:
> 
> > Jakub Kicinski <kuba@...nel.org> writes:
> > 
> > > On Thu, 20 Jun 2024 08:55:54 -0400 Aaron Conole wrote:
> > > > This series enhances the ovs-dpctl utility to provide support for set()
> > > > and tunnel() flow specifiers, better ipv6 handling support, and the
> > > > ability to add tunnel vports, and LWT interfaces.  Finally, it modifies
> > > > the pmtu.sh script to call the ovs-dpctl.py utility rather than the
> > > > typical OVS userspace utilities.
> > > 
> > > Thanks for the work! 
> > > 
> > > Looks like the series no longer applies because of other changes
> > > to the kernel config. Before it stopped applying we got some runs,
> > > here's what I see:
> > > 
> > > https://netdev-3.bots.linux.dev/vmksft-net/results/648440/3-pmtu-sh/stdout
> > > 
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS vxlan4: PMTU exceptions                             [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS vxlan4: PMTU exceptions - nexthop objects           [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv6, OVS vxlan4: PMTU exceptions                             [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv6, OVS vxlan4: PMTU exceptions - nexthop objects           [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS vxlan6: PMTU exceptions                             [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS vxlan6: PMTU exceptions - nexthop objects           [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv6, OVS vxlan6: PMTU exceptions                             [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv6, OVS vxlan6: PMTU exceptions - nexthop objects           [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS geneve4: PMTU exceptions                            [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS geneve4: PMTU exceptions - nexthop objects          [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv6, OVS geneve4: PMTU exceptions                            [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv6, OVS geneve4: PMTU exceptions - nexthop objects          [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS geneve6: PMTU exceptions                            [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv4, OVS geneve6: PMTU exceptions - nexthop objects          [FAIL]
> > > # Cannot find device "ovs_br0"
> > > # TEST: IPv6, OVS geneve6: PMTU exceptions                            [FAIL]
> > > # Cannot find device "ovs_br0"
> > > 
> > > Any idea why? Looks like kernel config did include OVS, perhaps we need
> > > explicit modprobe now? I don't see any more details in the logs.
> > 
> > Strange.  I expected that the module should have automatically been
> > loaded when attempting to communicate with the OVS genetlink family
> > type.  At least, that is how it had been working previously.
> > 
> > I'll spend some time looking into it and resubmit a rebased version.
> > Thanks, Jakub!
> 
> If the ovs module isn't available, then I see:
> 
> #   ovs_bridge not supported
> # TEST: IPv4, OVS vxlan4: PMTU exceptions                             [SKIP]
> 
> But if it is available, I haven't been able to reproduce such ovs_br0
> setup failure - things work.

I'm still wondering if the issue is Kconfig-related (plus possibly bad
interaction with vng). I don't see the OVS knob enabled in the self-
tests config. If it's implied by some other knob, and ends-up being
selected as a module, vng could stumble upon loading the module at
runtime, especially on incremental build (at least I experience that
problem locally). I'm not even sure if the KCI is building
incrementally or not, so all the above could is quite a wild guess.

In any case I think adding the explicit CONFIG_OPENVSWITCH=y the
selftest config would make the scenario more well defined.

Cheers,

Paolo