netdev - RE: [PATCH net-next v2 7/8] docs: netdev: break down the instance locking info per ops struct

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: <CO1PR11MB508998C288EEE2BFD2D45F44D6B72@CO1PR11MB5089.namprd11.prod.outlook.com>
Date: Thu, 10 Apr 2025 22:35:43 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "Dumazet, Eric" <edumazet@...gle.com>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "andrew+netdev@...n.ch"
	<andrew+netdev@...n.ch>, "horms@...nel.org" <horms@...nel.org>,
	"sdf@...ichev.me" <sdf@...ichev.me>, "hramamurthy@...gle.com"
	<hramamurthy@...gle.com>, "kuniyu@...zon.com" <kuniyu@...zon.com>, "Damato,
 Joe" <jdamato@...tly.com>
Subject: RE: [PATCH net-next v2 7/8] docs: netdev: break down the instance
 locking info per ops struct



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Thursday, April 10, 2025 9:08 AM
> To: Keller, Jacob E <jacob.e.keller@...el.com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Dumazet, Eric
> <edumazet@...gle.com>; pabeni@...hat.com; andrew+netdev@...n.ch;
> horms@...nel.org; sdf@...ichev.me; hramamurthy@...gle.com;
> kuniyu@...zon.com; Damato, Joe <jdamato@...tly.com>
> Subject: Re: [PATCH net-next v2 7/8] docs: netdev: break down the instance
> locking info per ops struct
> 
> On Wed, 9 Apr 2025 23:01:18 -0700 Jacob Keller wrote:
> > > +All queue management callbacks are invoked while holding the netdev
> instance
> > > +lock. ``rtnl_lock`` may or may not be held.
> > > +
> > > +Note that supporting struct netdev_queue_mgmt_ops automatically enables
> > > +"ops locking".
> > > +
> >
> > Does this mean we don't allow drivers which support
> > netdev_queue_mgmt_ops but don't set request_ops_lock? Or does it mean
> > that supporting netdev_queue_mgmt_ops and/or netdev shapers
> > automatically implies request_ops_lock? Or is there some other
> > behavioral difference?
> >
> > From the wording this sounds like its enforced via code, and it seems
> > reasonable to me that we wouldn't allow these without setting
> > request_ops_lock to true...
> 
> "request" is for drivers to optionally request.
> If the driver supports queue or shaper APIs it doesn't have a say.

Which is to say: if you support either of the new APIs, or you automatically get ops locking regardless of what request_ops_lock is, so that if you do support one of those interfaces, there is no behavioral difference between setting or not setting request_ops_lock.

Ok, I think that's reasonable.

Regards,
Jake