Phil Oester <kernel@xxxxxxxxxxxx> schrieb: >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). I see, thanks. >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? Printing a message sounds fine. But I think the main point of using locking is to provide a guarantee that a correct operation won't randomly fail. So I think we should retry forever. -- 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
