summaryrefslogtreecommitdiffstats
path: root/libiptc
Commit message (Collapse)AuthorAgeFilesLines
* libiptc: give credits to my selfJesper Dangaard Brouer2009-03-231-0/+5
| | | | | | | | Add notes about my scalability work on the library libiptc. This should make in more obvious who to complain to. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: fix whitespaces and typosJesper Dangaard Brouer2009-03-231-41/+41
| | | | | | | Cleanup whitespaces while going through the code. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: fix chain rename bug in libiptcJesper Dangaard Brouer2009-03-231-1/+8
| | | | | | | | | Chain renaming (TC_RENAME_CHAIN) can result in an unsorted chain list. That breaks the requirement of the binary search done in iptcc_bsearch_chain_index(). Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: avoid compile warnings for iptc_insert_chainChristoph Paasch2009-03-231-1/+1
| | | | | | | | iptc_insert_chain is too big to get inlined and so it generates a warning while compiling. Signed-off-by: Christoph Paasch <christoph.paasch@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: guard chain index allocation for different malloc implementationsJan Engelhardt2008-11-261-1/+1
| | | | | | | | Some libc implementations such as µClibc return NULL on malloc(0). They are free to do that per C standard. Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signeed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: make sockfd a per-handle thingJan Engelhardt2008-11-101-24/+14
| | | | | | | Get away from this singleton. Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: use hex output for hookmaskJan Engelhardt2008-11-101-2/+2
| | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove unused iptc_get_raw_socket and iptc_check_packetJan Engelhardt2008-11-103-26/+0
| | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove indirectionsJan Engelhardt2008-11-101-116/+113
| | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove typedef indirectionJan Engelhardt2008-11-103-73/+73
| | | | | | | | | | | Don't you hate it when iptc_handle_t *x actually is a double-indirection struct iptc_handle **? This also shows the broken constness model, since "const iptc_handle_t x" = "iptc_handle_t const x" = "struct iptc_handle *const x", which is like no const at all. Lots of things to do then. Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove old fixmeJesper Dangaard Brouer2008-09-241-2/+0
| | | | | | | Chains _are_ sorted, binary search depend on it! Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: fix scalability performance issue during initial ruleset parsingJesper Dangaard Brouer2008-07-031-11/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Finding jump chains is slow O(Chain*Rules). The problem: is that the chain list is searched lineary for each rule with a jump target. The problem lies in the "second pass" (of function parse_table) where the userchain jump targets are found. For each rule "R" with a IPTCC_R_JUMP target, function iptcc_find_chain_by_offset() searches through the chains "C" in the chain list (worst-case hitting the last one). The solution: in this patch is to speed up iptcc_find_chain_by_offset() by using binary search. Reducing complexity from O(C) to O(log C). Implementation: Its possible to use the same bsearch algorithm and data structure (chain_index), as used for chain name searching. How is that possible: One has to realize that the chains are both sorted by name and offsets, this is because the chains are already sorted in the ruleset from the kernel. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: minor bugfixJesper Dangaard Brouer2008-07-031-1/+2
| | | | | | | | Minor bugfix, an extra check is needed if the tail element is a builtin chain, as builtin chains are not sorted. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: move variable definitions to head of functionPatrick McHardy2008-06-071-2/+4
| | | | Signed-off-by: Patrick McHardy <kaber@trash.net>
* Use s6_addr32 to access bits in int6_addr instead of incompatible nameYasuyuki Kozakai2008-06-041-1/+1
| | | | | | | Spotted by Khem Raj <raj.khem@gmail.com> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Patrick McHardy <kaber@trash.net>
* Remove old functions, constantsJan Engelhardt2008-04-151-1/+2
|
* Combine IP{,6}T_LIB_DIR into XTABLES_LIBDIRJan Engelhardt2008-04-131-4/+0
|
* Fix all remaining warnings (missing declarations, missing prototypes)Jan Engelhardt2008-04-131-5/+4
|
* Fix -Wshadow warnings and clean up xt_sctp.hJan Engelhardt2008-04-061-27/+22
| | | | | Note: xt_sctp.h is still not merged upstream in the kernel as of this commit. But a refactoring was really needed.
* Retry ruleset dump when kernel returns EAGAIN.Patrick McHardy2008-04-021-1/+4
| | | | Bugzilla #104
* Remove obsolete filePatrick McHardy2008-01-201-24/+0
|
* Solving scalability issue: for chain list "name" searching.Jesper Dangaard Brouer2008-01-151-4/+414
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Solving scalability issue: for chain list "name" searching. Functions: iptcc_find_label(), iptc_is_chain(). Testing if a chain exist, requires a linearly walk of linked list with chain-names (doing a strcmp(3) in each step). Giving a worst-case runtime of O(n) where n is the number of chains. Why is this important to fix?! If only called once, this should not be a big concern, even-though the string compares are expensive. The performance issue arise with many chains for example; when using "iptables-restore", or when listing all "iptables -nL" rules, or when using CPAN IPTables::libiptc. Having 50k chains, the rule listing, with the command: "./iptables -nL > /dev/null", Without patch it takes approximately 5 minutes, With the patch it takes 0.5 seconds. Listing without patch: real 4m49.426s user 4m37.993s sys 0m0.280s Listing with patch: real 0m0.558s user 0m0.484s sys 0m0.064s How is it solved?! The issue is solved introducing a new data structure, that allow us to do binary search of chain names. Thus, reducing the worst-case runtime to O(log n). Being more specific: The new data structure is called "chain index", which is an array with pointers into the chain list, with CHAIN_INDEX_BUCKET_LEN spacing. This facilitates the ability to speedup chain list searching, by find a more optimal starting points when searching the linked list. The runtime complexity is actually also affected by this "bucket" size concept. Thus, O(log(n/k) + k) where k is CHAIN_INDEX_BUCKET_LEN. A nice property of the chain index, is that the "bucket" list length is max CHAIN_INDEX_BUCKET_LEN (when just build, inserts will change this). Oppose to hashing, where the "bucket" list length can vary a lot. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* Introduce a counter for number of user defined chains.Jesper Dangaard Brouer2008-01-151-1/+7
| | | | | | Introduce a counter for number of user defined chains. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* Inline functions iptcc_is_builtin() and set_changed().Jesper Dangaard Brouer2008-01-151-2/+2
| | | | | | | The two functions are obvious candidates for inlining. Using gprof(1) shows that they actually affects performance. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* More safe chain sorting, improving r7098Jesper Dangaard Brouer2007-12-121-1/+17
| | | | | | | | | | | | | | | | | This patch is an improvment of r7098 (made by me). Assuring compatibility between 1.4.0 and older versions, regarding chain sorting. Chains from kernel are already sorted, as they are inserted sorted. But there exists an issue when shifting to 1.4.0 from an older version, as old versions allow last created chain to be unsorted. This unsorted chain would survive in 1.4.0, as chains are now only sorted on creation. This patch verifies that chains are sorted, if not it fixes the sorting. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* Fix sockfd use accounting for kernels without autoloadingPatrick McHardy2007-12-041-4/+0
|
* iptables/libiptc perf issue: Sorting chain during pull-outJesper Dangaard Brouer2007-11-281-3/+3
| | | | | | | | | | | | | | | | | | | Performance optimize scalability issue: Sorting chain during pull-out give worst-case runtime O(Chains2). When pulling out the blob, every chain name is inserted alphabetically into a linked list (by function iptc_insert_chain()). The problem with this approach is that the chain names delivered in the blob is already sorted (as we push it back to the kernel sorted). This cause chain parsing to always process every element in the chain list and finish with a tail add. Causing worst-case runtime O(C2/2) for alphabetically sorting of chains. The patch solves this by only calling iptc_insert_chain() when creating new chains. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* Fix unused function warningPatrick McHardy2007-09-081-2/+1
|
* Fix more sparse warnings: non-C99 array declaration, incorrect function ↵Patrick McHardy2007-09-081-8/+8
| | | | prototypes
* Remove last vestiges of NFC (Peter Riley <Peter.Riley@hotpop.com>)Peter Riley2007-09-022-12/+4
|
* Removes KERNEL_64_USERSPACE_32Yasuyuki KOZAKAI2007-06-301-16/+0
| | | | | | | The recent kernel has compat layer for iptables. It doesn't have compat layer for libipq and ip6tables, but ip6tables with KERNEL_64_USERSPACE_32 is still broken. We should fix kernel instead of fixing them if and when we want use their 32bit binary with 64bit kernel.
* iptables -Z clears the per-rule counters, but not the chain policy counters ↵Andy Gay2006-08-221-0/+3
| | | | | | (Andy Gay <andy@andynet.net>) https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=502
* BUG: libiptc chain references bug (Jesper Brouer <hawk@diku.dk>)Patrick McHardyJesper Brouer2006-07-251-0/+8
| | | | | | | | | Correcting a chain references increment bug in libiptc. The bug lies in function iptc_delete_entry() / TC_DELETE_ENTRY. The problem is the construction of "r" the rule entry, that is used for comparison. The problem is that the function iptcc_map_target() increase the target chains references count.
* libiptc symbols clash (Phil Oester <kernel@linuxace.com>)Phil Oester2006-07-052-0/+4
| | | | | As reported by Dmitry Levin, the TC_NUM_RULES and TC_GET_RULE exports clash. His patch below, resolving bug #456
* Don't overwrite errno with return value of setsockopt (which is -1 on error).Patrick McHardy2006-04-221-6/+2
| | | | Fixes "Unknown error 4294967295" message (bugzilla #460).
* Revert incorrect fix for "Unknown error 4294967295" problemPatrick McHardyHarald Welte2006-04-221-2/+0
|
* When entering an invalid command (such as iptables -A INPUT -j MARK --set-markHarald Welte2006-04-211-0/+2
| | | | 1), the error message "Unknown error 4294967295" is displayed; (Closes: #460)
* don't install libiptc.aHarald Welte2006-02-091-1/+2
|
* - Fix memory leak in TC_COMMIT() (Markus Sundberg)Harald Welte2005-11-121-23/+25
| | | | | - Cleanup error path of TC_COMMIT() - Correctly propagate errors of setsockopt to calling function
* _really_ sort only user defined chains (Robert de Barth ↵Robert de Barth2005-07-311-1/+1
| | | | <list-netfilter@debarth.co.uk>
* get rid of numerous gcc-4 warningsHarald Welte2005-07-191-2/+2
|
* fix deletion of targets where kernel size != userspace size (Pablo Neira)Pablo Neira2005-06-232-0/+2
|
* Restore chain order (Olaf Rempel <razzor@kopf-tisch.de>)Olaf Rempel2005-03-041-4/+7
|
* Kill NFC_* stuff in iptables (Pablo Neira <pablo@eurodev.net>)Pablo Neira2005-02-142-22/+0
| | | | Fixes build with conntrack event patch for 2.6
* Revert the recent addition of memset()'s to TC_COMMIT. One of them is bogus ↵Phil Oester2005-02-041-3/+0
| | | | | | and the other one needs more investigation to why valgrind is complaining. Noticed and reverted by Phil Oester.
* re-implement alphabetic sorting to not confuse users who upgrade to 1.3.0Harald Welte2005-02-011-7/+18
|
* - Sets the 'iptc_fn' global variable to the pointer to the current functions ↵Derrik Pates2005-02-011-13/+36
| | | | | | | | in all major TC_* functions. This is necessary because in certain cases, an error return from a function that doesn't set 'iptc_fn' will conflict with a function-specific error return from one that does, causing TC_STRERROR() to return the wrong error string. This ensures that the right one will be returned. - Implements a simple reference counter for the netlink socket global variable 'sockfd'; this is necessary for IPTables::IPv4, where multiple tables (filter, nat, mangle, untracked) may be opened at one time. The way libiptc does it in the official version causes previously-opened tables to break such that attempts to commit changes will fail. - Adds a couple of memset() invocations in TC_COMMIT, based on past analysis with valgrind. It claimed that allocated structure were not being fully initialized, and adding the memset()s corrected this warning. (Derrik Pates <demon@devrandom.net>)
* Extension revision number support (if kernel supports the getsockopts).Rusty Russell2005-01-031-2/+2
| | | | | Enhance MARK match with second revision. Committed in anticipation of the kernel patch being applied.
* Stupid typo that meant we didn't compare target data when doing ↵Rusty Russell2004-12-291-1/+1
| | | | delete-by-matching-rule (found by nfsim test).
* Implement some optimization for finding rules to replace in TC_REPLACE_ENTRY.Martin Josefsson2004-12-181-2/+9
| | | | Stolen from TC_DELETE_NUM_ENTRY.
generated by cgit v1.2.3 (git 2.25.0) at 2024-11-01 00:05:06 +0000