netdev - RE: [RFC net-next] net: tc: flow indirect framework issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM5PR1301MB2172F573F9314D43F79D8F26E7EC9@DM5PR1301MB2172.namprd13.prod.outlook.com>
Date:   Wed, 13 Apr 2022 07:05:39 +0000
From:   Baowen Zheng <baowen.zheng@...igine.com>
To:     Mattias Forsblad <mattias.forsblad@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "roid@...dia.com" <roid@...dia.com>,
        "vladbu@...dia.com" <vladbu@...dia.com>,
        Eli Cohen <eli@...lanox.com>, Jiri Pirko <jiri@...nulli.us>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Vladimir Oltean <olteanv@...il.com>,
        Tobias Waldekranz <tobias@...dekranz.com>
Subject: RE: [RFC net-next] net: tc: flow indirect framework issue

On April 13, 2022 1:53 PM, Mattias wrote:
>Hello all,
>
>I'm currently working to get offloading of tc rules (clsact/matchall/drop) on a
>bridge offloaded to HW. The patch series is here:
>
>https://lore.kernel.org/netdev/20220411131619.43js6owwkalcdwwa@skbuf/
>T/#m07bff9e205e9ac03d15a4e758b4129235da88aba
>
>However I'm having some trouble with it. More specific in the limitations
>section in the link above, quote:
>
>Limitations
>If there is tc rules on a bridge and all the ports leave the bridge and then joins
>the bridge again, the indirect framwork doesn't seem to reoffload them at
>join. The tc rules need to be torn down and re-added. This seems to be
>because of limitations in the tc framework.
>
>The same issue can bee seen it you have a bridge with no ports and then adds
>a tc rule, like so:
>
>tc qdisc add dev br0 clsact
>tc filter add dev br0 ingress pref 1 proto all matchall action drop
>
>And then adds a port to that bridge
>ip link set dev swp0 master br0   <---- flow_indr_dev_register() bc this
Hi Mattias, in my understand, your problem may because you register your callback here. I am not sure why you choose to register your hook here(after the interface is added to the bridge to just trigger the callback in necessary case.)
Then your function is called and add your cb to the tcf_block. But since the matchall filter has been created so you can not get your callback triggered. 

Maybe you can try to regist your callback in your module load stage I think your callback will be triggered, or change the command order as: 
tc qdisc add dev br0 clsact
ip link set dev swp0 master br0
tc filter add dev br0 ingress pref 1 proto all matchall action drop
I am not sure whether it will take effect.
>
>I'm seeing the callback(TC_SETUP_BLOCK) from flow_indr_dev_register() but
>I'm not getting any callbacks that I've added via flow_block_cb_add()
>
>Do you maybe have some idea why I'm seeing this behavior?
>Am i doing something wrong or is it a known issue or something else?
>
>Best regards,
>
>Mattias Forsblad
>mattias.forsblad@...il.com