Re: [PATCH net-next] net: dummy: add phony ndo_setup_tc stub

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 10 Jun 2026 00:56:24 +0200 Pablo Neira Ayuso wrote:
> On Tue, Jun 09, 2026 at 04:28:09PM +0200, Florian Westphal wrote:
> > diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
> > index 9101b1703b52..26e7ed5a8575 100644
> > --- a/net/netfilter/nf_tables_offload.c
> > +++ b/net/netfilter/nf_tables_offload.c
> > @@ -234,6 +234,9 @@ bool nft_chain_offload_support(const struct nft_base_chain *basechain)
> >  				return false;
> >  
> >  			dev = ops->dev;
> > +			if (dev_net(dev)->user_ns != &init_user_ns)
> > +				return false;  
> 
> I have no idea how hardware offload can be used away from init_net_ns
> (not even init_user_ns). For most drivers, this exposes the same
> hardware offload capabilities for all netns, so they can interfer
> each?
> 
> @Jakub: Did you mention any driver that already support netns?
> Otherwise, maybe it is worth to restrict driver which do not explicit
> opt-in to netns support?

IDK if any SW driver can do it, I guess that's the risk here.

For HW drivers it doesn't matter which netns they are in, offload
should just work. But of course malicious users can't conjure up HW
devices, admin has to explicitly move the device into a netns.
Which is an explicit "permission grant".

The offload itself should be inherently netns aware since it should 
not cross netns boundaries?