Re: [PATCH iptables] iptables: support insisting that the lock is held

2017-05-19 Thread Lorenzo Colitti
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? > >

Re: [PATCH iptables] iptables: support insisting that the lock is held

2017-05-03 Thread Lorenzo Colitti
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 >

Re: [PATCH iptables] iptables: support insisting that the lock is held

2017-05-03 Thread Lorenzo Colitti
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 >

Re: [PATCH iptables] iptables: support insisting that the lock is held

2017-05-03 Thread Lorenzo Colitti
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

Re: [PATCH iptables] iptables: support insisting that the lock is held

2017-05-03 Thread Aaron Conole
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 >>>

Re: [PATCH iptables] iptables: support insisting that the lock is held

2017-05-03 Thread Aaron Conole
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

Re: [PATCH iptables] iptables: support insisting that the lock is held

2017-05-03 Thread Pablo Neira Ayuso
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