From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: netfilter-devel@vger.kernel.org, jscherpelz@google.com,
subashab@codeaurora.org, zlpnobody@gmail.com,
Narayan Kamath <narayan@google.com>
Subject: Re: [PATCH iptables v2 2/2] iptables-restore: support acquiring the lock.
Date: Tue, 21 Mar 2017 14:54:29 +0100 [thread overview]
Message-ID: <20170321135429.GA13317@salvia> (raw)
In-Reply-To: <20170316075502.2337-3-lorenzo@google.com>
On Thu, Mar 16, 2017 at 04:55:02PM +0900, Lorenzo Colitti wrote:
> Currently, ip[6]tables-restore does not perform any locking, so it
> is not safe to use concurrently with ip[6]tables.
>
> This patch makes ip[6]tables-restore wait for the lock if -w
> was specified. Arguments to -w and -W are supported in the same
> was as they are in ip[6]tables.
>
> The lock is not acquired on startup. Instead, it is acquired when
> a new table handle is created (on encountering '*') and released
> when the table is committed (COMMIT). This makes it possible to
> keep long-running iptables-restore processes in the background
> (for example, reading commands from a pipe opened by a system
> management daemon) and simultaneously run iptables commands.
>
> If -w is not specified, then the command proceeds without taking
> the lock.
>
> Tested as follows:
>
> 1. Run iptables-restore -w, and check that iptables commands work
> with or without -w.
> 2. Type "*filter" into the iptables-restore input. Verify that
> a) ip[6]tables commands without -w fail with "another app is
> currently holding the xtables lock...".
> b) ip[6]tables commands with "-w 2" fail after 2 seconds.
> c) ip[6]tables commands with "-w" hang until "COMMIT" is
> typed into the iptables-restore window.
> 3. With the lock held by an ip6tables-restore process:
> strace -e flock /tmp/iptables/sbin/iptables-restore -w 1 -W 100000
> shows 11 calls to flock and fails.
> 4. Run an iptables-restore with -w and one without -w, and check:
> a) Type "*filter" in the first and then the second, and the
> second exits with an error.
> b) Type "*filter" in the second and "*filter" "-S" "COMMIT"
> into the first. The rules are listed only when the first
> copy sees "COMMIT".
Applied, thanks Lorenzo.
prev parent reply other threads:[~2017-03-21 13:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-16 7:55 [PATCH iptables v2]: Support the iptables lock in ip[6]tables-restore Lorenzo Colitti
2017-03-16 7:55 ` [PATCH iptables v2 1/2] iptables: remove duplicated argument parsing code Lorenzo Colitti
2017-03-17 13:14 ` Pablo Neira Ayuso
2017-03-16 7:55 ` [PATCH iptables v2 2/2] iptables-restore: support acquiring the lock Lorenzo Colitti
2017-03-17 13:20 ` Pablo Neira Ayuso
2017-03-17 16:46 ` Lorenzo Colitti
2017-03-21 13:54 ` Pablo Neira Ayuso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170321135429.GA13317@salvia \
--to=pablo@netfilter.org \
--cc=jscherpelz@google.com \
--cc=lorenzo@google.com \
--cc=narayan@google.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=subashab@codeaurora.org \
--cc=zlpnobody@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.