linux-kernel - Re: [PATCH net-next v10 7/7] selftests: netconsole: validate target resume

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] [day] [month] [year] [list]

Message-ID: <20260117092227.741cba3b@kernel.org>
Date: Sat, 17 Jan 2026 09:22:27 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Andre Carvalho <asantostc@...il.com>
Cc: Breno Leitao <leitao@...ian.org>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Shuah Khan
 <shuah@...nel.org>, Simon Horman <horms@...nel.org>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v10 7/7] selftests: netconsole: validate target
 resume

On Fri, 16 Jan 2026 21:01:22 +0000 Andre Carvalho wrote:
> On Mon, Jan 12, 2026 at 06:16:42AM -0800, Jakub Kicinski wrote:
> > On Mon, 12 Jan 2026 09:40:58 +0000 Andre Carvalho wrote:  
> > > Introduce a new netconsole selftest to validate that netconsole is able
> > > to resume a deactivated target when the low level interface comes back.
> > > 
> > > The test setups the network using netdevsim, creates a netconsole target
> > > and then remove/add netdevsim in order to bring the same interfaces
> > > back. Afterwards, the test validates that the target works as expected.
> > > 
> > > Targets are created via cmdline parameters to the module to ensure that
> > > we are able to resume targets that were bound by mac and interface name.  
> > 
> > The new test seems to be failing in netdev CI:
> > 
> > TAP version 13
> > 1..1
> > # timeout set to 180
> > # selftests: drivers/net: netcons_resume.sh
> > # Running with bind mode: ifname
> > not ok 1 selftests: drivers/net: netcons_resume.sh # exit=1
> > -- 
> > pw-bot: cr  
> 
> I've finally been able to reproduce this locally. The issue is caused by the
> fact that the test currently expects that mac addresses for netdevsim devices are
> deterministic. This is the case on my setup as systemd enforces it (MACAddressPolicy=persistent).

Argh, systemd strikes again :(

> I was able to disable this behaviour by setting up /etc/systemd/network/50-netdevsim.link, with:
> 
> [Match]
> Driver=netdevsim
> 
> [Link]
> MACAddressPolicy=none
> 
> I'm assuming this is also the behaviour on CI hosts. 

Yes, systemd changing the MAC address is racy - it does it too slowly
and some tests start doing their thing, then systemd comes in and flips
the address. So indeed:

# cat /etc/systemd/network/99-default.link
[Match]
OriginalName=*

[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path mac
MACAddressPolicy=none

> I have started working on a fix
> for this test and will submit v11 once that is ready. The approach I'm taking is saving and
> restoring the mac addresses once I reload netdevsim module. Example code below (needs more testing):
> 
> function deactivate() {
> 	# Start by storing mac addresses so we can be restored in reactivate
> 	SAVED_DSTMAC=$(ip netns exec "${NAMESPACE}" \
> 		cat /sys/class/net/"$DSTIF"/address)
> 	SAVED_SRCMAC=$(mac_get "${SRCIF}")
> 	# Remove low level module
> 	rmmod netdevsim
> }
> 
> function reactivate() {
> 	# Add back low level module
> 	modprobe netdevsim
> 	# Recreate namespace and two interfaces
> 	set_network
> 	# Restore MACs
> 	ip netns exec "${NAMESPACE}" ip link set "${DSTIF}" \
> 		address "${SAVED_DSTMAC}"
> 	if [ "${BINDMODE}" == "mac" ]; then
> 		ip link set dev "${SRCIF}" down
> 		ip link set dev "${SRCIF}" address "${SAVED_SRCMAC}"
> 		# Rename device in order to trigger target resume, as initial
> 		# when device was recreated it didnt have correct mac address.
> 		ip link set dev "${SRCIF}" name "${TARGET}"
> 	fi
> }
> 
> The main annoyance is that to test resuming when a device was bound by mac I actually need
> to change the name of the device after restoring the mac address (since when the device 
> is registered after deactivation the mac won't match).

Workaround sounds reasonable, FWIW.