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: <20250410163908.07975fa9@kernel.org>
Date: Thu, 10 Apr 2025 16:39:08 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Keller, Jacob E" <jacob.e.keller@...el.com>
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

On Thu, 10 Apr 2025 22:35:43 +0000 Keller, Jacob E wrote:
> > > 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.

Right, and FWIW we may one day actually make the request_ops_lock 
bit be _the_ decider and auto-set it based on op presence when netdev
is registered. Purely to simplify the condition in netdev_need_ops_lock().
For now it isn't that. I was worried if I go into too much detail here
we'll then forget to update it and stale docs are worse than no docs :(