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

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

Message-ID: <20250111123522.7e4d1519@kernel.org>
Date: Sat, 11 Jan 2025 12:35:22 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
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 Sat, 11 Jan 2025 19:58:40 +0100 Andrew Lunn wrote:
> 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? 

Yes, we have both dummies which go thru alloc and static ones.

> 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?

You make a good point. Let me do the opposite, we only have two callers
of init_dummy_netdev(). Instead of unexporting it let me delete it
completely and make the two callers allocate the netdevs with
alloc_netdev_mqs().
-- 
pw-bot: cr