Hi, On Thu, Apr 30, 2020 at 05:08:31PM +0200, Pablo Neira Ayuso wrote: > On Thu, Apr 30, 2020 at 03:53:00PM +0200, Phil Sutter wrote: > > Hi Pablo, > > > > On Wed, Apr 29, 2020 at 11:36:09PM +0200, Pablo Neira Ayuso wrote: > > > On Tue, Apr 28, 2020 at 02:09:55PM +0200, Phil Sutter wrote: > > > > Hi Pablo, > > > > > > > > As promised, here's a revised version of your cache rework series from > > > > January. It restores performance according to my tests (which are yet to > > > > be published somewhere) and passes the testsuites. > > > > > > I did not test this yet, and I made a few rounds of quick reviews > > > alrady, but this series LGTM. Thank you for working on this. > > > > Cool! Should I push it or do you want to have a closer look first? > > You already took the time to test this, so I think it's fine if you > push out. Problems can be fixed from master. It would also good a few > runs to valgrind. OK, I'll play a bit with valgrind just to be sure and then push it out. > BTW, this cache consistency check > > commit 200bc399651499f502ac0de45f4d4aa4c9d37ab6 > Author: Phil Sutter <phil@xxxxxx> > Date: Fri Mar 13 13:02:12 2020 +0100 > > nft: cache: Fix iptables-save segfault under stress > > is already restored in this series, right? Yes, IIRC this was the reason why I got a merge conflict upon rebase. But the problem shouldn't exist with the new logic: We fetch cache just once, so there is no cache update (and potential cache free) happening while iterating through chain lists or anything. Cheers, Phil
