Re: [PATCH nf,v2 2/2] netfilter: nf_tables: call set ops .commit when building new ruleset

Pablo Neira Ayuso <[email protected]> wrote:
> The rbtree set only builds the b-search array after the new ruleset has
> been exposed through set ops .commit.
> 
> This is currently needed by pipapo because it purges the elements from
> the clone after the transactions are handled, therefore, pipapo still
> needs the delayed set ops .commit call after the transaction handling.
> 
> Allow the rbtree to call .commit before the transaction handling which
> purges the stale elements from the frontend rbtree datastructure.
> 
> Update rbtree .commit to skip deactivated and expired elements when
> building the new b-search array.

I'm not following, sorry.  What's the difference between pipapo and rbtree?

static void nft_pipapo_commit(struct nft_set *set)
{
[..]
        if (time_after_eq(jiffies, priv->last_gc + nft_set_gc_interval(set)))
                pipapo_gc_scan(set, priv->clone);

        old = rcu_replace_pointer(priv->match, priv->clone,
                                  nft_pipapo_transaction_mutex_held(set));

[..] after this, new incarnation is live.

static void nft_rbtree_commit(struct nft_set *set)
{
[..]
        if (time_after_eq(jiffies, priv->last_gc + nft_set_gc_interval(set)))
                nft_rbtree_gc_scan(set);

[ ... build the new blob ... ]

err_out:
        priv->array_next->num_intervals = num_intervals;
        old = rcu_replace_pointer(priv->array, priv->array_next,
                                  lockdep_is_held(&nft_pernet(read_pnet(&set->net))->commit_mutex));


[..] after this, new incarnation is live.

What is the problem?  These two functions do the same thing, no?
Why must the blob be rebuilt before stale node purge in rbtree case?