linux-kernel - Re: [net PATCH 2/2] selftests: forwarding: local

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]

Message-ID: <20241202115233.quxeapcw6g3uyj2x@skbuf>
Date: Mon, 2 Dec 2024 13:52:33 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Shuah Khan <shuah@...nel.org>, Petr Machata <petrm@...dia.com>,
	Benjamin Poirier <bpoirier@...dia.com>,
	Hangbin Liu <liuhangbin@...il.com>, Jiri Pirko <jiri@...nulli.us>,
	Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [net PATCH 2/2] selftests: forwarding: local_termination: sleep
 before starting tests

On Sat, Nov 30, 2024 at 12:33:10PM +0100, Christian Marangi wrote:
> It seems real hardware requires some time to stabilize and actually
> works after an 'ip link up'. This is not the case for veth as everything
> is simulated but this is a requirement for real hardware to permit
> receiving packet.
> 
> Without this the very fist test for unicast always fails on real
> hardware. With the introduced sleep of one second after mc_route_prepare,
> the test corretly pass as the packet can correctly be delivered.

I think the analysis is not very convincing for the following reason.

To wait after "ip link up", setup_wait() calls setup_wait_dev_with_timeout()
which waits until "ip link show dev $dev up" reports 'state UP'.
This comes from IFLA_OPERSTATE, set by linkwatch.

I remember having this conversation with Danielle Ratson a few years ago:
https://lore.kernel.org/netdev/20210624151515.794224-1-danieller@nvidia.com/
but the bottom line should be that, since commit facd15dfd691 ("net:
core: synchronize link-watch when carrier is queried") AFAIU, an operstate
of UP really means that the net device is ready of passing traffic. Failure
to do so should be a device-side problem.

Then I thought that maybe tcpdump needs some time to set up its filters
on the receving net device. But tcpdump_start() already has "sleep 1" in it.
I admit, that was purely empirical and there's no guarantee that tcpdump
has finished setting up even after 1 second. If you increase it to 2,
does it also solve your problem?

Or do you really have to place the sleep call after the mc_route_prepare() calls,
and any earlier won't help? In that case, it isolates the sleeping
requirement to the multicast routes themselves?