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: <20250226182717.0bead94b@kernel.org>
Date: Wed, 26 Feb 2025 18:27:17 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Gal Pressman <gal@...dia.com>
Cc: "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>,
 ecree.xilinx@...il.com
Subject: Re: [PATCH net-next] net: ethtool: Don't check if RSS context
 exists in case of context 0

On Wed, 26 Feb 2025 08:08:40 +0200 Gal Pressman wrote:
> On 26/02/2025 3:01, Jakub Kicinski wrote:
> > On Tue, 25 Feb 2025 09:13:48 +0200 Gal Pressman wrote:  
> >> Context 0 (default context) always exists, there is no need to check
> >> whether it exists or not when adding a flow steering rule.
> >>
> >> The existing check fails when creating a flow steering rule for context
> >> 0 as it is not stored in the rss_ctx xarray.  
> > 
> > But what is the use case for redirecting to context 0?  
> 
> I can think of something like redirecting all TCP traffic to context 1,
> and then a specific TCP 5-tuple to the default context.

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

> Anyway, it used to work.

To be clear unit tests don't count as "breaking real users",
and I assume the complaint comes from your QA team?

Given the weak definition of the ntuple API I'd prefer to
close this corner case. Unless someone feels strongly that
this should be allowed. If a real user complains we can both
fix and try to encode their flow into a selftest.

Let me CC Ed, too.