On Thu, Feb 16, 2023 at 12:29:30PM +0100, Pablo Neira Ayuso wrote: > On Thu, Feb 16, 2023 at 11:55:28AM +0100, Phil Sutter wrote: > > On Tue, Feb 07, 2023 at 11:56:53AM +0100, Phil Sutter wrote: > > [...] > > > Yes, please! I'll finish user space this week. :) > > > > Famous last words. :( > > > > I realized anonymous sets are indeed a problem, and I'm not sure how it > > could be solved. I missed the fact that with lookup expressions one has > > to run the init() callback to convert their per-batch set ID into the > > kernel-defined set name. So the simple "copy and return nla" approach is > > not sufficient. > > > > Initializing all of the dump-only expressions though causes other > > unwanted side-effects, like e.g. duplicated chain use-counters. > > > > One could ban lookup from being used in dump-only expressions. Right > > now, only ebtables' among match requires it. > > > > To still allow for ebtables-nft to use the compat interface, among match > > could be rewritten to use the legacy extension in-kernel. This doesn't > > solve the original problem though, because old ebtables-nft versions > > can't parse a match expression containing among extension. > > > > Another option that might work is to parse the dump-only expressions in > > nf_tables_newrule(), dump them into an skb, drop them again and extract > > the skb's buffer for later. > > > > Do you have a better idea perhaps? I'm a bit clueless how to proceed > > further right now. :( > > I'll drop the patch from nf-next and we take more time to think how to > solve this. ACK! > This problem is interesting, but it is difficult! Yes, it is. Maybe a feasible solution is to scan through the dump-only expression nla and update any lookup ones manually. Pretty ugly though, because it breaks the attribute encapsulation in expressions. > Does this work for you? Yes, thanks! Cheers, Phil
