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] [day] [month] [year] [list]

Message-ID: <Z66wpiW71N42uLSL@mini-arch>
Date: Thu, 13 Feb 2025 18:55:34 -0800
From: Stanislav Fomichev <stfomichev@...il.com>
To: Saeed Mahameed <saeed@...nel.org>
Cc: Stanislav Fomichev <sdf@...ichev.me>, 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 02/13, Saeed Mahameed wrote:
> 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.

Hey Saeed,

There is a follow up which locks the other paths:
https://lore.kernel.org/netdev/20250210192043.439074-1-sdf@fomichev.me/

I'm gonna try to do a v2 tomorrow to address Jakub's feedback. There is no
opt-in currently; any driver that uses shaper/queue-mgmt API will have
its ndo running with the instance lock. Can you try to run your mlx5
queue-mgmt changes on top of it? (v1 should be good enough, no need to
wait for v2)