On Wed, May 3, 2017 at 11:51 PM, Aaron Conole <aconole@xxxxxxxxxx> wrote: > I've thought about it. I think a better change that makes sense in the > presence of concurrent updates would be to use the wait argument as a > total time, and apply it to both the userspace lock, AND an EAGAIN from > the kernel space side. So if the kernel space says 'locked try again', > and the user passed a -w option, we can simply keep retrying until the > wait time expires. Does that make sense and solve your issue, Lorenzo? The lock is always taken regardless of whether -w is specified. The only difference is that with -w userspace waits instead of exiting with an error. I'm with Pablo on this one - the behaviour is incorrect and should be fixed. Admins shouldn't have to wait for a concurrent execution to happen before they know that they misconfigured the lock. I think that if the admin runs iptables and the lock is unusable, it's a configuration error, and it should be reported as such immediately. Also - even if we add a check for EAGAIN, how reliable is that codepath going to be? Concurrent updates are already pretty rare, and the problem we saw was pretty hard to track down. If we sprinkle checks for EAGAIN all over the code, and a future change misses one of them, how will anyone notice breakage? -- 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
