linux-kernel - Re: [PATCH net-next v11 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXFIk1L8G_dHF6od@archlinux>
Date: Wed, 21 Jan 2026 22:04:23 +0000
From: Andre Carvalho <asantostc@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
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 v11 7/7] selftests: netconsole: validate target
 resume

Hi Jakub,

On Tue, Jan 20, 2026 at 05:20:57PM -0800, Jakub Kicinski wrote:
> On Sun, 18 Jan 2026 11:00:27 +0000 Andre Carvalho wrote:
> > +++ b/tools/testing/selftests/drivers/net/netcons_resume.sh
> 
> There's too many of them now and they keep failing on real HW.

Since these tests are only using netdevsim I was a bit surprised about the failures
on real HW runs.

I'm suspecting a race on my workaround to trigger reactivation and these runs
potentially running on a host with systemd with MACAddressPolicy=persistent as
I'm able to produce a similar error on this conditions. Any chance these are
running with different configuration then SW runs?

When the device is recreated with the same MAC address as before, there is a race
between my workaround and the resume. netconsole will immediately resume and UP
the device, then my workaround goes and:

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 didn't have correct mac address.
ip link set dev "${SRCIF}" name "${TARGET}"

The problem is that the rename won't resume, as the target has already not deactivated
and nothing will UP the device. 

Doing "ip link set dev "${TARGET}" up" at this point should address this gap. Alternative,
we can skip restoring the mac addresses if they are the same.

Does this make sense? Perhaps there are other conditions that can trigger this, but
running it with MACAddressPolicy=persistent is a reliable way for me to reproduce it.

> We'll keep this series in the queue but I think it's time to move 
> the netcons tests out to their own target or move them to netdevsim.

Given the above, let me know if you prefer I send v12 with the proposed fixes or
a separated follow up patch to fix the test on HW runs. Since you mentioned keeping
on the queue I want to make sure a new version of this series won't mess up your process.

> With absolutely no error message getting printed :|

Yes, debugging these has been quite challenging. I'd like to improve all netconsole
selftests debuggability in a future series, looking to work on this as soon as I wrap
this one up.

> 
> TAP version 13
> 1..1
> # overriding timeout to 360
> # selftests: drivers/net: netcons_resume.sh
> # Running with bind mode: ifname
> # ifname : Test passed
> # Running with bind mode: mac
> not ok 1 selftests: drivers/net: netcons_resume.sh # exit=1
> 
> https://netdev-3.bots.linux.dev/vmksft-drv-hw-dbg/results/482560/4-netcons-resume-sh/stdout

-- 
Andre Carvalho