summaryrefslogtreecommitdiffstats
path: root/iptables/xshared.c
Commit message (Collapse)AuthorAgeFilesLines
* xshared: using the blocking file lock request when we wait indefinitelyLiping Zhang2017-02-281-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using "-w" to avoid concurrent instances, we try to do flock() every one second until it success. But one second maybe too long in some situations, and it's hard to select a suitable interval time. So when using "iptables -w" to wait indefinitely, it's better to block until it become success. Now do some performance tests. First, flush all the iptables rules in filter table, and run "iptables -w -S" endlessly: # iptables -F # iptables -X # while : ; do iptables -w -S >&- & done Second, after adding and deleting the iptables rules 100 times, measure the time cost: # time for i in $(seq 100); do iptables -w -A INPUT iptables -w -D INPUT done Before this patch: real 1m15.962s user 0m0.224s sys 0m1.475s Apply this patch: real 0m1.830s user 0m0.168s sys 0m1.130s Signed-off-by: Liping Zhang <zlpnobody@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* xshared: do not lock again and again if "-w" option is not specifiedLiping Zhang2017-02-281-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | After running the following commands, some confusing messages was printed out: # while : ; do iptables -A INPUT & iptables -D INPUT & done [...] Another app is currently holding the xtables lock; still -9s 0us time ahead to have a chance to grab the lock... Another app is currently holding the xtables lock; still -29s 0us time ahead to have a chance to grab the lock... If "-w" option is not specified, the "wait" will be zero, so we should check whether the timer_left is less than wait_interval before we call select to sleep. Also remove unused "BASE_MICROSECONDS" and "struct timeval waited_time" introduced by commit e8f857a5a151 ("xtables: Add an interval option for xtables lock wait"). Fixes: e8f857a5a151 ("xtables: Add an interval option for xtables lock wait") Signed-off-by: Liping Zhang <zlpnobody@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* xtables: Add an interval option for xtables lock waitSubash Abhinov Kasiviswanathan2016-07-031-8/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ip[6]tables currently waits for 1 second for the xtables lock to be freed if the -w option is used. We have seen that the lock is held much less than that resulting in unnecessary delay when trying to acquire the lock. This problem is even severe in case of latency sensitive applications. Introduce a new option 'W' to specify the wait interval in microseconds. If this option is not specified, the command sleeps for 1 second by default. v1->v2: Change behavior to take millisecond sleep as an argument to -w as suggested by Pablo. Also maintain current behavior for -w to sleep for 1 second as mentioned by Liping. v2->v3: Move the millisecond behavior to a new option as suggested by Pablo. v3->v4: Use select instead of usleep. Sleep every iteration for the time specified in the "-W" argument. Update man page. v4->v5: Fix compilation error when enabling nftables v5->v6: Simplify -W so it only takes the interval wait in microseconds. Bail out if -W is specific but -w is not. Joint work with Pablo Neira. Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* xshared: calm down compilation warningPablo Neira Ayuso2015-02-181-0/+1
| | | | | | | xshared.c: In function ‘xtables_lock’: xshared.c:255:3: warning: implicit declaration of function ‘flock’ [-Wimplicit-function-declaration] Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* iptables: use flock() instead of abstract unix socketsPablo Neira Ayuso2015-01-201-15/+7
| | | | | | | | | | | | | Abstract unix sockets cannot be used to synchronize several concurrent instances of iptables since an unpriviledged process can create them and prevent the legitimate iptables instance from running. Use flock() and /run instead as suggested by Lennart Poettering. Fixes: 93587a0 ("ip[6]tables: Add locking to prevent concurrent instances") Reported-by: Lennart Poettering <lennart@poettering.net> Cc: Phil Oester <kernel@linuxace.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* iptables: add optional [seconds] argument to -wJiri Popelka2014-07-251-3/+5
| | | | | | | | | | | | | | | | | | | | | | This patch adds an optional numeric argument to -w option (added with 93587a0) so one can specify how long to wait for an exclusive lock. If the value isn't specified it works as before, i.e. program waits indefinitely. If user specifies it, program exits after the given time interval passes. This patch also adds the -w/--wait to nftables compat code, so the parser doesn't complain. [ In the original patch, iptables-compat -w X was not working, I have fixed by adding the dummy code not to break scripts using the new optional argument --pablo ] Signed-off-by: Jiri Popelka <jpopelka@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* ip[6]tables: Add locking to prevent concurrent instancesPhil Oester2013-06-111-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There have been numerous complaints and bug reports over the years when admins attempt to run more than one instance of iptables simultaneously. Currently open bug reports which are related: 325: Parallel execution of the iptables is impossible 758: Retry iptables command on transient failure 764: Doing -Z twice in parallel breaks counters 822: iptables shows negative or other bad packet/byte counts As Patrick notes in 325: "Since this has been a problem people keep running into, I'd suggest to simply add some locking to iptables to catch the most common case." I started looking into alternatives to add locking, and of course the most common/obvious solution is to use a pidfile. But this has various downsides, such as if the application is terminated abnormally and the pidfile isn't cleaned up. And this also requires a writable filesystem. Using a UNIX domain socket file (e.g. in /var/run) has similar issues. Starting in 2.2, Linux added support for abstract sockets. These sockets require no filesystem, and automatically disappear once the application terminates. This is the locking solution I chose to implement in ip[6]tables. As an added bonus, since each network namespace has its own socket pool, an ip[6]tables instance running in one namespace will not lock out an ip[6]tables instance running in another namespace. A filesystem approach would have to recognize and handle multiple network namespaces. Signed-off-by: Phil Oester <kernel@linuxace.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* src: resolve old macro names that are indirectionsJan Engelhardt2011-09-111-1/+1
| | | | | | | | | | | Command used: git grep -f <(pcregrep -hior '(?<=#define\s)IP6?(T_\w+)(?=\s+X\1)' include/) and then fix all occurrences. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* extensions: support for per-extension instance "global" variable spaceJan Engelhardt2011-06-211-0/+18
| | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* iptables: consolidate target/match init callJan Engelhardt2011-06-211-2/+13
| | | | | | | This is useful for the upcoming patch about per-instance auxiliary data. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* option: fix ignored negation before implicit extension loadingJan Engelhardt2011-06-071-5/+7
| | | | | | | | | | | | `iptables -A INPUT -p tcp ! --syn` forgot the negation, i.e. it was not present in a subsequent `iptables -S`. Commit v1.4.11~77^2~9 missed the fact that after autoloading a proto extension, cs.invert must not be touched until the next getopt call. This is now fixed by having command_default return a value to indicate whether to jump or not. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* src: move all iptables pieces into a separate directoryJan Engelhardt2011-06-071-0/+207
(Unclutter top-level dir) Signed-off-by: Jan Engelhardt <jengelh@medozas.de>