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

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

[Florian Westphal]

Allow to use dummy driver to test offload control plane code.

Unlike netdevsim, dummy is a data sink so no capabilities (e.g.
u32-style matcher, vport device redirects, PPPoE header push/pop etc).
have to be implemented.

Tag the offload callback to permit error injection to test rollback/abort
code in nf_tables.

At this time, nf_tables has an upfront check for offload capabilities to
avoid exposure of offload code paths on machines that lack capable
hardware.  With this patch, dummy can always "offload" which exposes this
functionality.  Given real hardware will normally live in the initial
namespace, restrict the offload to initial user ns instead.

Signed-off-by: Florian Westphal <fw@strlen.de>
---
 drivers/net/dummy.c               | 10 ++++++++++
 net/netfilter/nf_tables_offload.c |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index f6732eab5923..b31ad10eb958 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -85,6 +85,15 @@ static int dummy_change_carrier(struct net_device *dev, bool new_carrier)
 	return 0;
 }
 
+static int dummy_setup_tc(struct net_device *dev, enum tc_setup_type type, void *type_data)
+{
+	if (dev_net(dev)->user_ns != &init_user_ns)
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+ALLOW_ERROR_INJECTION(dummy_setup_tc, ERRNO);
+
 static const struct net_device_ops dummy_netdev_ops = {
 	.ndo_init		= dummy_dev_init,
 	.ndo_start_xmit		= dummy_xmit,
@@ -93,6 +102,7 @@ static const struct net_device_ops dummy_netdev_ops = {
 	.ndo_set_mac_address	= eth_mac_addr,
 	.ndo_get_stats64	= dummy_get_stats64,
 	.ndo_change_carrier	= dummy_change_carrier,
+	.ndo_setup_tc		= dummy_setup_tc,
 };
 
 static const struct ethtool_ops dummy_ethtool_ops = {
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;
+
 			if (!dev->netdev_ops->ndo_setup_tc &&
 			    !flow_indr_dev_exists())
 				return false;
-- 
2.53.0

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

[Jakub Kicinski]

On Tue,  9 Jun 2026 16:28:09 +0200 Florian Westphal wrote:
> Unlike netdevsim, dummy is a data sink so no capabilities (e.g.
> u32-style matcher, vport device redirects, PPPoE header push/pop etc).
> have to be implemented.

If no "peer" is configured netdevsim is also a data sink.

We added netdevsim because dummy and veth started accumulating
"features" which were clearly just for test harnesses. Would be
great if we could stay the course and put whatever changes you
need in netdevsim, even if it requires some hacks.

Is there anything fundamentally blocking the use of netdevsim?
Or is it just convenience (since netdevsim is a bit of a PITA
to create and establish the name of)?

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

[Florian Westphal]

Jakub Kicinski <kuba@kernel.org> wrote:
> On Tue,  9 Jun 2026 16:28:09 +0200 Florian Westphal wrote:
> > Unlike netdevsim, dummy is a data sink so no capabilities (e.g.
> > u32-style matcher, vport device redirects, PPPoE header push/pop etc).
> > have to be implemented.
> 
> If no "peer" is configured netdevsim is also a data sink.

Yes, but you can configure peers.  And then this fake offload stub
is a liar.

I would expect that offloads for netdevsim actually work, i.e.
that a shaper shapes, that ets offload does delay packets and
in case of flowtable that it will move skbs from one vport to
another (if that was requested).

> We added netdevsim because dummy and veth started accumulating
> "features" which were clearly just for test harnesses. Would be
> great if we could stay the course and put whatever changes you
> need in netdevsim, even if it requires some hacks.

Is a lot more work.  I don't have time ATM to implement a u32-style
packet matcher or a fake software flowtable.

> Is there anything fundamentally blocking the use of netdevsim?
> Or is it just convenience (since netdevsim is a bit of a PITA
> to create and establish the name of)?

I played with netdevsim, aside from the above (i.e., I don't expect
netdevsim to say 'offloaded' and then ignore all the offloaded
commands...) the worst part is the naming and the behaviour when
creating new devices while in a network namespace.  Test is spawned via
'unshare -n' -- I did not find a way to really extract the new device name
reliably except via 'ip link'.

I think thats solveable, so yes, I could make netdevsim lie instead.

But I don't think its the right thing to do.

If you disagree and think that this is fine I can retarget this to
netdevsim, no problem.

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

[Jakub Kicinski]

On Wed, 10 Jun 2026 00:25:30 +0200 Florian Westphal wrote:
> Jakub Kicinski <kuba@kernel.org> wrote:
> > On Tue,  9 Jun 2026 16:28:09 +0200 Florian Westphal wrote:  
> > > Unlike netdevsim, dummy is a data sink so no capabilities (e.g.
> > > u32-style matcher, vport device redirects, PPPoE header push/pop etc).
> > > have to be implemented.  
> > 
> > If no "peer" is configured netdevsim is also a data sink.  
> 
> Yes, but you can configure peers.  And then this fake offload stub
> is a liar.
> 
> I would expect that offloads for netdevsim actually work, i.e.
> that a shaper shapes, that ets offload does delay packets and
> in case of flowtable that it will move skbs from one vport to
> another (if that was requested).
> 
> > We added netdevsim because dummy and veth started accumulating
> > "features" which were clearly just for test harnesses. Would be
> > great if we could stay the course and put whatever changes you
> > need in netdevsim, even if it requires some hacks.  
> 
> Is a lot more work.  I don't have time ATM to implement a u32-style
> packet matcher or a fake software flowtable.

There are no real requirements on how netdevsim behaves. The only
requirement is that there's an in-tree test that uses whatever
functionality is being added. So you can implement the features
to whatever depth you need for your current testing.

> > Is there anything fundamentally blocking the use of netdevsim?
> > Or is it just convenience (since netdevsim is a bit of a PITA
> > to create and establish the name of)?  
> 
> I played with netdevsim, aside from the above (i.e., I don't expect
> netdevsim to say 'offloaded' and then ignore all the offloaded
> commands...) the worst part is the naming and the behaviour when
> creating new devices while in a network namespace.  Test is spawned via
> 'unshare -n' -- I did not find a way to really extract the new device name
> reliably except via 'ip link'.

Yes :( we have some helpers in 
tools/testing/selftests/drivers/net/netdevsim/ethtool-common.sh
among other places but libraries are a PITA in ksft as well.

> I think thats solveable, so yes, I could make netdevsim lie instead.
> 
> But I don't think its the right thing to do.
> 
> If you disagree and think that this is fine I can retarget this to
> netdevsim, no problem.

Yes, I'd prefer netdevsim. If nothing else it lets us discard 
"security reports" by saying that nobody should have netdevsim 
loaded on a production system.

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

[Pablo Neira Ayuso]

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?

Thanks.

> +
>  			if (!dev->netdev_ops->ndo_setup_tc &&
>  			    !flow_indr_dev_exists())
>  				return false;
> -- 
> 2.53.0
> 
> 

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

[Jakub Kicinski]

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?