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: <20250227072933.5bbb4e2c@kernel.org>
Date: Thu, 27 Feb 2025 07:29:33 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Edward Cree <ecree.xilinx@...il.com>
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 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?

> On other implementations which use the rule number as a
>  position (like the API/naming implies) you could insert the
>  5-tuple rule first and that would work too.
> 
> > Oh, I think Ed may tell us that using context 0 + queue offset is legit.  
> 
> I hadn't actually thought of that, but yes that's true too.
> 
> Anyway, 'mechanism, not policy' says we should allow ctx 0
>  unless there's some mechanism reason why it can't be
>  supported, and I don't see one.

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". Or am I missing something magical that
ctx 0 would do that's not 100% the same as pass (modulo the queue
offset)? Using ctx 0 as implicit pass is a very easy thing to miss
for driver developers.

But yeah, the queue offset is legit.