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

From: Florian Westphal <[email-masked]>
Date: Sun, 15 Feb 2026 14:06:42 +0100

Jakub Kicinski <[email-masked]> wrote:
> On Fri, 13 Feb 2026 12:30:58 +0100 Florian Westphal wrote:
> > > > Looking at the *upper layer*, I don't think it expected drivers to use
> > > > a single global list for this bit something that is scoped to the
> > > > net_device.  
> > > 
> > > Maybe subjective but the fix seems a little off to me.
> > > Isn't flow_block_cb_setup_simple() just a "simple" implementation 
> > > for reuse in drivers locking in there doesn't really guarantee much?  
> > 
> > Not sure what you mean.  I see the same pattern as netdevsim in all
> > drivers using this API. 
> 
> Grep for flow_block_cb_add(). Not all drivers use

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?
How is ownership handled, what locks protect, or what locks are supposed
to protect this?

> the flow_block_cb_setup_simple() helper, it's just a convenience helper,
> not a mandatory part of the flow. We should probably add a helper for
> add like the one added for  flow_block_cb_remove_driver() instead of
> taking the lock directly in flow_block_cb_setup_simple()?

No idea, I don't understand how any of this is supposed to work.

I will try to play with this next week but I'm not sure I will send
patches.  AFAICS there are not even netdevsim based tests for this
feature anywhere.