On Sat, Jul 15, 2023 at 02:59:25PM +0200, Phil Sutter wrote:
> While testing/analyzing the changes in commit 4e95200ded923, I noticed
> comparison of rules containing among matches was not behaving right. In
> fact, most part of the among match data was ignored when comparing, due
> to the way among extension scales its payload. This problem exists since
> day 1 of the extension implementation for ebtables-nft. Patch 1 fixes
> this by placing a hash of the "invisible" data in well-known space.
>
> Patch 2 is a minor cleanup of commit 4e95200ded923, eliminating some
> ineffective function signature changes.
>
> Patch 3 adds set (with element) dumps to debug output.
>
> Note about 4e95200ded923 itself: I don't quite like the approach of
> conditionally converting a rule into libnftnl format using only compat
> expressions for extensions. I am aware my proposed compatibility mode
> does the same, but it's a global switch changing add_match() behaviour
> consistently. What the commit above does works only because for rule
> comparison, both rules are converted back into iptables_command_state
> objects. I'd like to follow an alternative path of delaying the
> rule conversion so that it does not happen in nft_cmd_new() but later
> from nft_action() (or so). This should eliminate some back-and-forth and
> also implicitly fix the case of needless set creation.
>
> Phil Sutter (3):
> extensions: libebt_among: Fix for false positive match comparison
> nft: Do not pass nft_rule_ctx to add_nft_among()
> nft: Include sets in debug output
Applied the last two patches of this series. Patch 1 turned out to be
ineffective (due to frequent collisions). A proper solution is contained
in commit 10583537004f7 ("nft: Special casing for among match in
compare_matches()").
