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 09:20:29 -0400
From: Aaron Conole <aconole@...hat.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Jakub Kicinski <kuba@...nel.org>,  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.

Paolo Abeni <pabeni@...hat.com> writes:

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

That is in 7/7 - but there was a collision with a netfilter knob getting
turned on.  I can repost it as-is (just after rebasing) if you think
that is the only issue.

> Cheers,
>
> Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ