Subject: Re: [PATCH net] net: flow_offload: protect driver_block_list in flow_block_cb_setup_simple()

From: Jakub Kicinski <[email-masked]>
Date: Tue, 17 Feb 2026 14:05:45 -0800

On Tue, 17 Feb 2026 12:42:13 +0100 Pablo Neira Ayuso wrote:
> > static int
> > mtk_eth_setup_tc_block(struct net_device *dev, struct flow_block_offload *f)
> > {
> >         struct mtk_mac *mac = netdev_priv(dev);
> >         struct mtk_eth *eth = mac->hw;
> >         static LIST_HEAD(block_cb_list);
> > 	~~~~~~
> > I have a question.
> > 
> > [..]
> >         f->driver_block_list = &block_cb_list;
> > 
> > Now I have many questions!
> > 
> > How is this supposed to work?  
> 
> Last time I met people, I asked how is hw offload actually working
> with netns (6 years ago?), someone told me: "maybe there is a driver
> that supports it...". I have never seen one, but I am very much
> outdates on how this has evolved TBH, I might be wrong.
> 
> I don't think any driver really supports netns + hardware offload, so
> I suggest to restrict it, see attached patch.
> 
> It would be better to add a helper function such as int net_setup_tc()
> for the myriad of ->ndo_setup_tc() calls in the code, then move this
> check in it to consolidate, but I think you want something you can
> pass to -stable at this stage?

I don't think we need this restriction for TC side, it should be under
rtnl_lock, IIUC. I have a... strong suspicion(?) that TC works, some
drivers explicitly support devlink reload into a specified netns. 
I always assumed this is for the cases where something like OvS offload
is supposed to be handled outside init_net to avoid netdev explosion. 
I could be wrong, tho, could be an RDMA thing.