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: <53429226-6058-4aae-baf1-666ba7f8cf0a@intel.com>
Date: Fri, 11 Apr 2025 14:26:23 -0700
From: Jacob Keller <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



On 4/10/2025 4:39 PM, Jakub Kicinski wrote:
> 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 :(

Yea. I don't think the doc itself needs more comment. My questions are
also for my own education as to whats going on, and to make sure I
understood what the code and docs are saying now.

Thanks,
Jake