From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: "A. Sverdlin" <alexander.sverdlin@siemens.com>
Cc: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests: net: local_termination: Wait for interfaces to come up
Date: Wed, 5 Nov 2025 23:31:37 +0200 [thread overview]
Message-ID: <20251105213137.2knkuovcc3jpnhqv@skbuf> (raw)
In-Reply-To: <20251104061723.483301-1-alexander.sverdlin@siemens.com>
On Tue, Nov 04, 2025 at 07:17:21AM +0100, A. Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
>
> It seems that most of the tests prepare the interfaces once before the test
> run (setup_prepare()), rely on setup_wait() to wait for link and only then
> run the test(s).
>
> local_termination brings the physical interfaces down and up during test
> run but never wait for them to come up. If the auto-negotiation takes
> some seconds, first test packets are being lost, which leads to
> false-negative test results.
Yes, sorry, dropping the link is an unfortunate, undesirable and
unaccounted for side effect of simple_if_init and simple_if_fini,
mainly used for moving the IP addresses from the physical to the various
virtual upper interfaces.
>
> Use setup_wait_dev() after corresponding simple_if_init() on physical
> interfaces to make sure auto-negotiation has been completed and test
> packets will not be lost because of the race against link establishment.
>
> The wait has to be done in each individual test because the interfaces
> have to be brough up first and only then we can wait for link (not
> individually, because they are expected to be looped in pairs).
>
> Fixes: 90b9566aa5cd3f ("selftests: forwarding: add a test for local_termination.sh")
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> ---
> .../selftests/net/forwarding/local_termination.sh | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/testing/selftests/net/forwarding/local_termination.sh b/tools/testing/selftests/net/forwarding/local_termination.sh
> index ecd34f364125c..369c8b2c1f4a2 100755
> --- a/tools/testing/selftests/net/forwarding/local_termination.sh
> +++ b/tools/testing/selftests/net/forwarding/local_termination.sh
> @@ -430,6 +430,8 @@ standalone()
> h1_create
> h2_create
> macvlan_create $h2
> + setup_wait_dev $h1
> + setup_wait_dev $h2
>
> run_test $h1 $h2 $skip_ptp $no_unicast_flt "$h2"
>
> @@ -448,6 +450,8 @@ test_bridge()
> bridge_create $vlan_filtering
> simple_if_init br0 $H2_IPV4/24 $H2_IPV6/64
> macvlan_create br0
> + setup_wait_dev $h1
> + setup_wait_dev $h2
>
> run_test $h1 br0 $skip_ptp $no_unicast_flt \
> "vlan_filtering=$vlan_filtering bridge"
> @@ -480,6 +484,8 @@ test_vlan()
> h1_vlan_create
> h2_vlan_create
> macvlan_create $h2.100
> + setup_wait_dev $h1
> + setup_wait_dev $h2
>
> run_test $h1.100 $h2.100 $skip_ptp $no_unicast_flt "VLAN upper"
>
> @@ -505,6 +511,8 @@ vlan_over_bridged_port()
> h2_vlan_create
> bridge_create $vlan_filtering
> macvlan_create $h2.100
> + setup_wait_dev $h1
> + setup_wait_dev $h2
>
> run_test $h1.100 $h2.100 $skip_ptp $no_unicast_flt \
> "VLAN over vlan_filtering=$vlan_filtering bridged port"
> @@ -536,6 +544,8 @@ vlan_over_bridge()
> simple_if_init br0
> vlan_create br0 100 vbr0 $H2_IPV4/24 $H2_IPV6/64
> macvlan_create br0.100
> + setup_wait_dev $h1
> + setup_wait_dev $h2
>
> if [ $vlan_filtering = 1 ]; then
> bridge vlan add dev $h2 vid 100 master
> --
> 2.51.1
>
Functionally I have nothing against this change.
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Two ideas to minimize the delta in a more obviously correct way.
They can perhaps be implemented together, independently of one another,
or not at all:
- setup_wait() could be used directly, as it waits for $NUM_NETIFS, aka
$h1 and $h2.
- There is no case where run_test() does not need a prior setup_wait()
call, so it can just as well be placed as the first thing of that
function.
next prev parent reply other threads:[~2025-11-05 21:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 6:17 [PATCH] selftests: net: local_termination: Wait for interfaces to come up A. Sverdlin
2025-11-05 21:31 ` Vladimir Oltean [this message]
2025-11-06 14:53 ` Paolo Abeni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251105213137.2knkuovcc3jpnhqv@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=alexander.sverdlin@siemens.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox