On Wed, Sep 27, 2023 at 05:53:17PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230927152514.473765-1-pablo@xxxxxxxxxxxxx/ > > > > Ouch, still fails. Damn, I don't get a proper fix for this script. > > What about restoring an expire value of 3s, then check there is *one* > element, wait 4s, check element is gone? > > Tests are parallelized, so this won't cause noticeable slowdown. :) I have been running tests for a while and it seems no more spurious errors show with: https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230927163937.757167-1-pablo@xxxxxxxxxxxxx/ Not related, next one to look at is: W: [DUMP FAIL] 31/378 testcases/sets/0062set_connlimit which occasionally fails. This is because this adds an element: table ip x { set est-connlimit { type ipv4_addr size 65535 flags dynamic elements = { 84.245.120.167 ct count over 20 } } } the conncount list is empty, then GC might win race to delete this element with no entries (GC removes empty conncount lists). I added this test to make sure this restores fine, even if GC removes all elements that has been restored as soon as it gets a chance to run, because the conncount list is empty. For this one, I can set a larger gc-interval, so GC takes longer time to release it, and still parser coverage for this restoration remains in place.
