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: Mon, 24 Jun 2024 12:53:45 -0400
From: Aaron Conole <aconole@...hat.com>
To: 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>,  Paolo Abeni <pabeni@...hat.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.

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.

My branch is rebased on 568ebdaba6370c03360860f1524f646ddd5ca523

Additionally, the "Cannot find device ..." text comes from an iproute2
utility output.  The only place we actually interact with that is via
the call at pmtu.sh:973:

	run_cmd ip link set ovs_br0 up

Maybe it is possible that the link isn't up (could some port memory
allocation or message be delaying it?) yet in the virtual environment.
To confirm, is it possible to run in the constrained environment, but
put a 5s sleep or something?  I will add the following either as a
separate patch (ie 7/8), or I can fold it into 6/7 (and drop Stefano's
ACK waiting for another review):


wait_for_if() {
   if ip link show "$2" >/dev/null 2>&1; then return 0; fi

   for d in `seq 1 30`; do
      sleep 1
      if ip link show "$2" >/dev/null 2>&1; then return 0; fi
   done
   return 1
}

....
 	setup_ovs_br_internal || setup_ovs_br_vswitchd || return $ksft_skip
+	wait_for_if "ovs_br0"
 	run_cmd ip link set ovs_br0 up
....

Does it make sense or does it seem like I am way off base?