Add parameter option in module xt_ACCOUNT.ko to accept. Change in the
ACCOUN_MAX_TABLES table without the need to recompile the module.
References: MR-8
Commit 613dbd95723aee7abd16860745691b6c7bda20dc (netfilter:
x_tables: move hook state into xt_action_param structure) changes the
struct xt_action_param, accommodate for it.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
xt_ACCOUNTing objects create in one network namespace could be
read from all namespaces. Also object with the same name in
different namespaces would collide.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
Below is the patch with the *rest* of the free_page(X) calls changed
to free_pages(X, 2). xt_ACCOUNT should always allocate memory in page
pairs. And always *free* memory in page pairs.
References: http://www.spinics.net/lists/netfilter-devel/msg39025.html
The Smoothwall Express traffic stats collector (traffiClogger) does
not handle counter rollovers well and does not perform read&flush.
(Yes, the code is somewhat aged.) To change it to perform read&flush
is non-trivial. Then, it occurred to me that it might be easier to
change ipt_ACCOUNT in xtables-addons to use 64-bit counters,
considering it was designed around single kernel pages.
The following submission counts to at least 100 GB, produces no
obvious kernel gripes, and adjacent counters do not seem to interfere
with each other. Yes, it uses more memory, but RAM costs much less
than bugs that grown out of complex software.
The theory:
- Use two kernel pages for the counters for each group of 256
addresses.
- Change counters to 64-bit.
- Change to __get_free_pages/free_pages, using order=2
(two consecutive pages), and zero both pages.
- Change "%u" to "%llu" as needed.
- Everything else pretty much stays the same.
I also changed tmpbuf to two pages (Justin Case's idea), but I
do not know if that's really necessary.
