On Sat, Aug 24, 2019 at 06:53:34PM +0200, Pablo Neira Ayuso wrote: > On Wed, Aug 21, 2019 at 11:26:02AM +0200, Phil Sutter wrote: > [...] > > +/* XXX: move this into libnftnl, replacing nftnl_set_lookup() */ > > +static struct nftnl_set *nft_set_byname(struct nft_handle *h, > > + const char *table, const char *set) > > Probably extend libnftnl to allow to take a pointer to a nftnl_set > object, as an alternative to the set name? The idea is that this > set object now belongs to the lookup extension, so this extension will > take care of releasing it from the destroy path. > > Then, the lookup extension will have a pointer to the anonymous set so > you could then skip the cache code (and all the updates to have access > to it). Sounds like a nice approach! So I would add a new NFTNL_EXPR_LOOKUP_SET_PTR to link the set and introduce NFTA_LOOKUP_ANON_SET (or so) which starts a nested attribute filled simply by nftnl_set_nlmsg_build_payload()? Kernel code would have to be extended accordingly, of course. Seems like I can't reuse nftnl_set_nlmsg_parse() since mnl_attr_parse_nested() would have to be called. But I guess outsourcing the attribute handling from the further and introducing a second wrapper would do. Also, this would limit ebtables-nft among match to kernels supporting this new way of anon set creating. > Anonymous sets can only be attached to one rule and they go away when > the rule is released. Then, flushing the rule would also release this > object. Luckily, in kernel space it seems like anonymous sets are released automatically if the referencing rule is removed. Cheers, Phil
