Re: [PATCH] xtables: Add locking to prevent concurrent instances

[Phil Oester <kernel@linuxace.com>]

On Wed, May 22, 2013 at 09:29:06PM +0200, Patrick McHardy wrote:
> If I'm not mistaken, we retry failed operations since a few years now, so is this actually still a problem? 
> 
> If so, why abort after three tries instead of waiting until the lock can be acquired?

Not sure what you are referring to with retrying operations.  The race condition
between multiple simultaneous instances of iptables running still exists in
latest git.  For example, fire up a few simultanous instances of this:

# while : ;  do iptables -A INPUT -j ACCEPT ; iptables -D INPUT -j ACCEPT ; done
iptables: Resource temporarily unavailable.
iptables: Resource temporarily unavailable.
iptables: Invalid argument. Run `dmesg' for more information.
iptables: Resource temporarily unavailable.
iptables: Resource temporarily unavailable.

Bug 764 is another race problem where two simultaneous "iptables -Z" causes
counters to get reset to invalid numbers (and is reproducible with current git).  

As to your second question re: why only three tries (in 3 seconds): I suppose we
could just wait "forever".  In most normal cases I wouldn't expect a wait > 1
second for an instance to complete.  But there could be pathological corner cases
such as dumping a huge ruleset with DNS resolution (i.e. without -n) which could
take an eternity to complete.  Should we spit out (to stderr) some kind of
message in these cases, or just sit silently?  Perhaps every 5 seconds?

Phil