Jakub Kicinski [off-list ref] wrote:

On Fri, 13 Feb 2026 12:30:58 +0100 Florian Westphal wrote:

quoted

quoted

quoted

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.