netdev - Re: [RFC net-next 0/4] net: Hold netdev instance lock during ndo operations

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: <Z66mEzg1YU02mr43@x130>
Date: Thu, 13 Feb 2025 18:10:27 -0800
From: Saeed Mahameed <saeed@...nel.org>
To: Stanislav Fomichev <sdf@...ichev.me>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com
Subject: Re: [RFC net-next 0/4] net: Hold netdev instance lock during ndo
 operations

On 04 Feb 15:00, Stanislav Fomichev wrote:
>As the gradual purging of rtnl continues, start grabbing netdev
>instance lock in more places so we can get to the state where
>most paths are working without rtnl. Start with requiring the
>drivers that use shaper api (and later queue mgmt api) to work
>with both rtnl and netdev instance lock. Eventually we might
>attempt to drop rtnl. This mostly affects iavf, gve, bnxt and
>netdev sim (as the drivers that implement shaper/queue mgmt)
>so those drivers are converted in the process.
>
>This is part one of the process, the next step is to do similar locking
>for the rest of ndo handlers that are being called from sysfs/ethtool/netlink.

Hi Stan, thanks for the patch, sorry I didn't have the time that week to
look at it and it fill between the cracks, I've glanced through the patches
quickly and they seem reasonable. but obviously we need much more, 
so what's the plan? currently I am not able to personally work on
this. 

Also the locking scheme is still not well define with this opt-in idea the
locking shceme is actually still not clear to me?  for me it should be as easy
as netdev_lock protects all paths including, ndos/ioctl/netlinks/etc .. paths
that will access the netdev's underlying driver queues.