Florian Westphal <fw@xxxxxxxxx> 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.
