Re: update element timeout support [was Re: [PATCH nf 1/2] netfilter: nft_set_rbtree: move sync GC from insert path to set->ops->commit]

[Florian Westphal <fw@strlen.de>]

Florian Westphal <fw@strlen.de> wrote:
> > You mean, from the preparation phase? Then we need to undo what has
> > been done, in case of --check / abort path is exercised, this might
> > just create a bogus element listing.
> 
> True.  Am I correct that we can't implement the "expand" via
> del+add because of stateful objects?
> 
> I fear we will need to circle back to rbtree then, I'll followup
> there (wrt. on-demand gc).

Found another corner case, lets assume rhash set to not mix it
with the rbtree issue.

Element E exists and has not timed out yet

Userspace generates:
Refresh timeout of E to <bignum>
<other unrelated stuff, time passes, E expires>
Add E again.  As existing E has timed out already,
this passes...

How to prevent an outcome where E now exists twice?

Variant:
Refresh timeout of E to <bignum>
Delete E

Care has to be taken to not add UAF here.

ATM deletion (unlink) would take effect before the sets' commit
hooks are called, so we refresh timeout of an unlinked element.

AFAICS there won't be UAF because the element memory won't be
released until after mutex unlock and synchronize_rcu, but its
not nice either.