On Wed, May 29, 2013 at 02:23:33PM -0400, Phil Oester wrote: > On Wed, May 29, 2013 at 02:59:03PM +0200, Pablo Neira Ayuso wrote: > > I think we can: > > > > * Add a new option to explicitly request this behaviour, just as a way > > to assert that you really want iptables to retry. Harald was rising > > some concerns on the expected results in case of clash that sound > > reasonable to me. > > I agree that the retry behaviour could be made optional, however > I'm not sure that the locking behaviour should be optional. It leads > to various races, some of which are subtle and can occur during if-up > and other "behind the scenes" scenarios. In my personal experience, > I had to implement locking inside my scripts because I was hitting > races fairly regularly with dynamic rule additions/deletions (and I > suspect other admins have done the same). Perhaps we can change the > error to say: > > "Another app is currently holding the ip[6]tables lock (use -r option to enable retries)" That seems reasonable to me. > or something similar? At least that is more informative than the typical > race error of "iptables: Resource temporarily unavailable". > > > * Limit this to ip[6]tables. All bug reports refer to it. > > Seems reasonable. If future races are discovered in -save or -restore, > it could be easily changed. Good. Would you send us a new patch? Thanks. -- 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
