Red Hat Bugzilla – Bug 453814
Adding many iptables rules fails on archs with large NR_CPUS
Last modified: 2014-06-18 04:01:45 EDT
Description of problem:
Since the rule table is sized according to NR_CPUS, the code in
net/ipv4/netfilter/ip_tables.c applies an overflow check when loading new rule sets:
/* overflow check */
if (tmp.size >= (INT_MAX - sizeof(struct xt_table_info)) / NR_CPUS -
This limits the number of rules that can be loaded on e.g. x86_64 (NR_CPUS==255)
to a lower number than the 32-bit kernel permits (NR_CPUS==32).
Recompiling the kernel with a lower NR_CPUS allows the problem to be avoided but
is obviously not a great solution.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Anything that will load a huge number of rules works, e.g.:
1. Fill /etc/sysconfig/iptables with a very large number of rules (~250,000 -
exact number depends on size/complexity of rules)
2. Use iptables-restore to reload the rules
iptables-restore: line 240468 failed
iptables gets an ENOMEM from the above code in do_replace.
Works as expected.
The 64-bit kernel should not be more limited in this respect than the 32-bit kernel.
This was fixed upstream with the "xt_table_info-diet" patches:
Author: Eric Dumazet <email@example.com>
Date: Tue Dec 4 23:24:56 2007 -0800
[NETFILTER]: x_tables: struct xt_table_info diet
Instead of using a big array of NR_CPUS entries, we can compute the size
needed at runtime, using nr_cpu_ids
This should save some ram (especially on David's machines where NR_CPUS=409
32 KB can be saved per table, and 64KB for dynamically allocated ones (beca
of slab/slub alignements) )
In particular, the 'bootstrap' tables are not any more static (in data
section) but on stack as their size is now very small.
This also should reduce the size used on stack in compat functions
(get_info() declares an automatic variable, that could be bigger than kerne
stack size for big NR_CPUS)
Signed-off-by: Eric Dumazet <firstname.lastname@example.org>
Signed-off-by: Patrick McHardy <email@example.com>
Signed-off-by: David S. Miller <firstname.lastname@example.org>
Created attachment 310838 [details]
xt_table_info diet for rhel5
I started working on a backport of this code to RHEL5 but ran out of time -
problem I was having was s390x not defining nr_cpu_ids & breaking the runtime
net/netfilter/x_tables.c: In function 'xt_alloc_table_info':
net/netfilter/x_tables.c:409: error: 'nr_cpu_ids' undeclared (first use in this
net/netfilter/x_tables.c:409: error: (Each undeclared identifier is reported
net/netfilter/x_tables.c:409: error: for each function it appears in.)
make: *** [net/netfilter/x_tables.o] Error 1
make: *** [net/netfilter] Error 2
make: *** Waiting for unfinished jobs....
net/sctp/sm_statefuns.c: In function 'sctp_eat_data':
net/sctp/sm_statefuns.c:5174: warning: unused variable 'account_value'
net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie':
net/sctp/sm_make_chunk.c:1350: warning: initialization discards qualifiers from
pointer target type
net/sctp/ulpevent.c: In function 'sctp_ulpevent_release_owner':
net/sctp/ulpevent.c:114: warning: unused variable 'skb'
make: *** [net] Error 2
+ exit 1
Also not sure the changes are kABI safe..
It's kABI safe so far. But nr_cpu_ids not the problem of s390x, kernel-2.6.18
does not have nr_cpu_ids definition at all.
/me took the bug in work-queue...
disregard my notice about kABI... it's unsafe.