On Tue, Oct 13, 2020 at 12:08:03PM +0200, Phil Sutter wrote: [...] > On Mon, Oct 12, 2020 at 02:54:50PM +0200, Pablo Neira Ayuso wrote: > [...] > > Patch LGTM, thanks Phil. > > > > What I don't clearly see yet is what scenario is triggering the bug in > > the existing code, if you don't mind to explain. > > See the test case attached to the patch: An other iptables-restore > process may add references (i.e., jumps) to a chain the own > iptables-restore process wants to delete. This should not be a problem > because these references are added to a chain that is being flushed by > the own process as well. But if that chain doesn't exist while the own > process fetches kernel's ruleset, this flush job is not created. Let me rephrase this: 1) process A fetches the ruleset, finds no chain C (no flush job then) 2) process B adds new chain C, flush job is present 3) process B adds the ruleset 4) process A appends rules to the existing chain C (because there is no flush job) Is this the scenario? If so, I wonder why the generation ID is not helping to refresh and retry.
