> Is there any protection built into the protocol to prevent concurrent > writes from clobbering each other? Ah, I think I see the reason for the behaviour that I'm seeing. It looks like the kernel does check that the number of entries in the table hasn't changed since the data was read [1] That explains why the unrelated rule change in my second script causes the COMMIT to fail. [1] https://github.com/torvalds/linux/blob/master/net/ipv4/netfilter/ip_tables.c#L1033 On 4 February 2017 at 08:53, Shaun Crampton <shaun@xxxxxxxxxx> wrote: >> This is by design; the RMW cycle in principle also affects the "slower" >> iptables - which is why it is slower, because it does only one rule per cycle. > > Thanks for the response. I understand that the RMW is by design. Is there > any protection built into the protocol to prevent concurrent writes from > clobbering each other? I thought I'd read that there was a "version" > on the read > that let the kernel spot if a write was stale. > > My second script acts as if there is; the commits of the "kube" loop > fail reliably > rather than clobbering the writes of the "felix" loop. However, > that's not the case > for the first script. I'm wondering if there is supposed to be > protection but it's > bugged. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
