netdev - Re: [PATCH net-next] net: ethtool: Don't check if RSS context exists in case of context 0

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: <c034259f-ec9a-2e78-1fc0-f16981cd4e54@gmail.com>
Date: Thu, 27 Feb 2025 16:24:52 +0000
From: Edward Cree <ecree.xilinx@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Gal Pressman <gal@...dia.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, netdev@...r.kernel.org,
 Andrew Lunn <andrew@...n.ch>, Simon Horman <horms@...nel.org>,
 Joe Damato <jdamato@...tly.com>, Tariq Toukan <tariqt@...dia.com>
Subject: Re: [PATCH net-next] net: ethtool: Don't check if RSS context exists
 in case of context 0

On 27/02/2025 15:29, Jakub Kicinski wrote:
> On Thu, 27 Feb 2025 15:18:47 +0000 Edward Cree wrote:
>> On 27/02/2025 04:45, Jakub Kicinski wrote:
>>> The ordering guarantees of ntuple filters are a bit unclear.
>>> My understanding was that first match terminates the search,
>>> actually, so your example wouldn't work :S  
>>
>> My understanding is that in most ntuple implementations more-
>>  specific filters override less-specific ones, in which case
>>  Gal's setup would work.
> 
> The behavior of partially overlapping rules being undefined?

In the general case yes; for our implementation I think there's
 a total order of match masks defined by firmware that extends
 the partial order from the subset relation.  (Unlike our MAE
 implementation for *TC* rules on ef100, where it really is
 undefined.)

> I never uttered the thought that lead me to opposing. 
> ctx 0 is a poor man's pass / accept. If someone needs a pass we should
> add an explicit "action pass".

To me 'pass' is just a shorthand for whatever specific behaviour
 happens to match the default.  I.e. if you can already express
 that behaviour directly, then 'pass' is a strictly nonorthogonal
 addition and therefore bad interface design.
But then, I'm the guy who thinks ed(1) is a good UI, so...

> Or am I missing something magical that
> ctx 0 would do that's not 100% the same as pass (modulo the queue
> offset)?

Nothing comes to mind.

> Using ctx 0 as implicit pass is a very easy thing to miss
> for driver developers.

I don't see why drivers need anything special to handle "0 is
 pass".  They need to handle "0 isn't in the xarray" (so map it
 to the default HW context), which I suppose we ought to call out
 explicitly in the struct ethtool_rxnfc kdoc if we're going to
 continue allowing it, but it's not the fact that it's "an
 implicit pass" that makes this necessary.  If there's something
 I'm missing here please educate me :)