Re: [PATCH nf-next 3/9] netfilter: nft_set_pipapo: prepare destroy function for on-demand clone

[Florian Westphal <fw@strlen.de>]

Stefano Brivio <sbrivio@redhat.com> wrote:
> > I do not follow.  nft_pipapo_destroy() is not invoked asynchronously via
> > call_rcu, its invoked from either abort path or the gc work queue at at
> > time where there must be no references to nft_set anymore.
> 
> Hmm, sorry, I was all focused on nft_set_pipapo_match_destroy()
> accessing nft_set, but that has nothing to do with
> pipapo_reclaim_match(). However:
> 
> > What do we wait for, i.e., which outstanding rcu callback could
> > reference a data structure that nft_pipapo_destroy() will free?
> 
> ...we still have pipapo_free_match(), called by pipapo_reclaim_match(),
> referencing the per-CPU scratch areas, and nft_pipapo_destroy() freeing
> them (using pipapo_free_match() since this patch).

But those scratchmaps are anchored in struct nft_pipapo_match.

So, if we have a call_rcu() for struct nft_pipapo_match $m, and then
get into nft_pipapo_destroy() where priv->match == $m or
priv->clone == $m we are already in trouble ($m is free'd twice).

If not, then I don't see why ordering would matter.

Can you sketch a race where pipapo_reclaim_match, running from a
(severely delayed) call_rcu, will access something that has been
released already?

I can't spot anything.