linux-kernel - Re: [PATCH net-next v2 5/6] netconsole: resume previously deactivated target

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4evp3lo4rg7lh2qs6gunocnk5xlx6iayruhb6eoolmah6qu3fp@bwwr3sf5tnno>
Date: Tue, 23 Sep 2025 20:30:39 +0100
From: Andre Carvalho <asantostc@...il.com>
To: Breno Leitao <leitao@...ian.org>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, 
	"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>, 
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v2 5/6] netconsole: resume previously
 deactivated target

Hi Breno,

On Tue, Sep 23, 2025 at 05:22:25AM -0700, Breno Leitao wrote:
> For targets that are set by the mac address, they don't necessarily get
> np.dev_name populated, do they?
> 
> I am double checking netpoll_setup(), and if
> is_valid_ether_addr(np->dev_mac), I don't see np.dev_name being
> populated.

I was not expecting it to be the case either, bu my understanding is that 
np.dev_name does get populated by __netpoll_setup, which is called unconditionally 
at the end of netpoll_setup. __netpoll_setup eventually does:

np->dev = ndev;
strscpy(np->dev_name, ndev->name, IFNAMSIZ);

I've confirmed that for targets bound by mac, np->dev_name is empty before these
lines but then it is correctly populated here. For targets create by name,
np->dev_name is already correctly set prior to this. 
Please, let me know if I'm missing something.

> Should we also compare that the mac doesn't match before returning?

Even though the above seem to work on my tests, I was not 100% sure we wanted
to also check the dev_name when we initially bound by mac.
I've also considered the approach below, which I think achieves what you are
suggesting:

if (!is_broadcast_ether_addr(nt->np.dev_mac)) {
	if(memcmp(nt->np.dev_mac, ndev->dev_addr, ETH_ALEN))
		return;
} else if (strncmp(nt->np.dev_name, ndev->name, IFNAMSIZ)) {
        return;
}

Let me know if you prefer this approach, it would allow resuming targets in case
even if their dev_name changes.

> --breno