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 -- 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
