netdev - Re: [PATCH net-next v5 5/6] flow_offload: support get flow

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]

Date:   Sat, 3 Aug 2019 07:19:31 +0800
From:   wenxu <wenxu@...oud.cn>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     jiri@...nulli.us, pablo@...filter.org, fw@...len.de,
        netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
        John Hurley <john.hurley@...ronome.com>
Subject: Re: [PATCH net-next v5 5/6] flow_offload: support get flow_block
 immediately


在 2019/8/3 2:02, Jakub Kicinski 写道:
> On Fri, 2 Aug 2019 21:09:03 +0800, wenxu wrote:
>>>> We'd have something like the loop in flow_get_default_block():
>>>>
>>>> 	for each (subsystem)
>>>> 		subsystem->handle_new_indir_cb(indr_dev, cb);
>>>>
>>>> And then per-subsystem logic would actually call the cb. Or:
>>>>
>>>> 	for each (subsystem)
>>>> 		block = get_default_block(indir_dev)
>>>> 		indr_dev->ing_cmd_cb(...)  
>>>             nft dev chian is also based on register_netdevice_notifier, So for unregister case,
>>>
>>> the basechian(block) of nft maybe delete before the __tc_indr_block_cb_unregister. is right?
>>>
>>> So maybe we can cache the block as a list of all the subsystem in  indr_dev ?  
>>
>> when the device is unregister the nft netdev chain related to this device will also be delete through netdevice_notifier
>>
>> . So for unregister case,the basechian(block) of nft maybe delete before the __tc_indr_block_cb_unregister.
> Hm, but I don't think that should be an issue. The ordering should be
> like one of the following two:
>
> device unregister:
>   - driver notifier callback
>     - unregister flow cb
>       - UNBIND cb
>         - free driver's block state
>     - free driver's device state
>   - nft block destroy
>     # doesn't see driver's CB any more
>
> Or:
>
> device unregister:
>   - nft block destroy
>     - UNBIND cb
>       - free driver's block state
>   - driver notifier callback
>     - free driver's state
>
> No?

For the second case maybe can't unbind cb? because the nft block is destroied. There is no way

to find the block(chain) in nft.


>
>> cache for the block is not work because the chain already be delete and free. Maybe it improve the prio of
>>
>> rep_netdev_event can help this?
> In theory the cache should work in a similar way as drivers, because
> once the indr_dev is created and the initial block is found, the cached
> value is just recorded in BIND/UNBIND calls. So if BIND/UNBIND works for
> drivers it will also put the right info in the cache.
>