netdev - Re: [PATCH net-next 02/11] net: hold netdev instance lock during ndo_setup

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] [day] [month] [year] [list]

Message-ID: <20250211195703.57b5a6d1@kernel.org>
Date: Tue, 11 Feb 2025 19:57:03 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Stanislav Fomichev <stfomichev@...il.com>
Cc: Stanislav Fomichev <sdf@...ichev.me>, netdev@...r.kernel.org,
 davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com, Saeed Mahameed
 <saeed@...nel.org>
Subject: Re: [PATCH net-next 02/11] net: hold netdev instance lock during
 ndo_setup_tc

On Tue, 11 Feb 2025 19:48:50 -0800 Stanislav Fomichev wrote:
> > The netfilter / flow table offloads don't seem to test tc_can_offload(),
> > should we make that part of the check optional in dev_setup_tc() ?
> > Add a bool argument to ignore  tc_can_offload() ?  
> 
> Let me dig into it... I was assuming that tc_can_offload() is basically
> a runtime way to signal to the core that even though the device has
> ndo_setup_tc defined, the feature can't be used.
> 
> I don't understand why some places care only about ndo_setup_tc
> while other test for both ndo_setup_tc/tc_can_offload. Do you by
> chance have any context on this? Does tc_can_offload cover only
> a subset of (TC_SETUP_BLOCK) the offload types?
> 
> The easiest way is probably just to keep calls to tc_can_offload outside,
> as is, but I was thinking that doing both ndo_setup_tc and tc_can_offload
> is a bit more safe.

Off the top of my head the feature flag was added when John pioneered
the opportunistic offload of TC classifiers. It seems to have also
propagated to switch-like Qdisc offloads. The answer is probably some
mix of historic precedent (non-switch qdisc offload like mqprio exited
way before), features which are unambiguously HW-facing, and plain
omissions.

Let's do whatever is easiest here, the series touches half of the
stack, we can't possibly clean up all encountered.. mysteries.