On Thu, May 4, 2017 at 12:57 AM, Lorenzo Colitti wrote:
> > I would like to skip this compile time switch, if the existing
> > behaviour is broken, we should just fix it. What is the scenario that
> > can indeed have an impact in terms of backward compatibility breakage?
> >
On Wed, May 3, 2017 at 11:51 PM, Aaron Conole 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
>
On Wed, May 3, 2017 at 11:27 PM, Aaron Conole wrote:
> I wouldn't say it that way. I looked at this a while ago, and one thing
> to keep in mind is the if the particular prefix path in the filesystem
> (for instance /run) isn't available, then this will cause iptables to
>
On Wed, May 3, 2017 at 8:01 PM, Pablo Neira Ayuso wrote:
> This sounds to me like a wrong design decision was made when
> introducing this userspace lock.
Looks like the lock was introduced by
93587a04d0f2 ("ip[6]tables: Add locking to prevent concurrent instances")
which
Aaron Conole writes:
> Pablo Neira Ayuso writes:
>
>> On Thu, Apr 20, 2017 at 06:23:33PM +0900, Lorenzo Colitti wrote:
>>> Currently, iptables programs will exit with an error if the
>>> iptables lock cannot be acquired, but will silently continue if
>>>
Pablo Neira Ayuso writes:
> On Thu, Apr 20, 2017 at 06:23:33PM +0900, Lorenzo Colitti wrote:
>> Currently, iptables programs will exit with an error if the
>> iptables lock cannot be acquired, but will silently continue if
>> the lock cannot be opened at all.
>
> This sounds
On Thu, Apr 20, 2017 at 06:23:33PM +0900, Lorenzo Colitti wrote:
> Currently, iptables programs will exit with an error if the
> iptables lock cannot be acquired, but will silently continue if
> the lock cannot be opened at all.
This sounds to me like a wrong design decision was made when