netdev - Re: [PATCH net-next 2/2] net: initialize netdev->lock on dummy devices

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: <30c4dfe3-8991-4659-8379-47f0ac0d6f31@lunn.ch>
Date: Sat, 11 Jan 2025 19:58:40 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
	pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org
Subject: Re: [PATCH net-next 2/2] net: initialize netdev->lock on dummy
 devices

On Fri, Jan 10, 2025 at 10:59:55PM -0800, Jakub Kicinski wrote:
> Make sure netdev->lock is always valid, even on dummy netdevs.
> 
> Apparently it's legal to call mutex_destroy() on an uninitialized
> mutex (and we do that in free_netdev()), but it doesn't seem right.
> Plus we'll soon want to take netdev->lock on more paths which dummy
> netdevs may reach.

I assume here that dummy does not call alloc_netdev_mqs() or one of it
wrappers? That is how the lock seems to get initialised for real MAC
drivers. Are there other bits of initialisation in that function which
dummy is missing? Should we really be refactoring alloc_netdev_mqs()
to expose an initialisation helper for everything which is not related
queues?

	Andrew