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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190802110216.5e1fd938@cakuba.netronome.com>
Date:   Fri, 2 Aug 2019 11:02:16 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     wenxu <wenxu@...oud.cn>
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

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?

> 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.