@@ -1668,7 +1668,7 @@ __nf_conntrack_alloc(struct net *net,
/* We don't want any race condition at early drop stage */
ct_count = atomic_inc_return(&cnet->count);
- if (nf_conntrack_max && unlikely(ct_count > nf_conntrack_max)) {
+ if (unlikely(ct_count > nf_conntrack_max)) {
if (!early_drop(net, hash)) {
if (!conntrack_gc_work.early_drop)
conntrack_gc_work.early_drop = true;
@@ -648,7 +648,7 @@ static struct ctl_table nf_ct_sysctl_table[] = {
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = SYSCTL_ZERO,
+ .extra1 = SYSCTL_ONE,
.extra2 = SYSCTL_INT_MAX,
},
[NF_SYSCTL_CT_COUNT] = {
@@ -929,7 +929,7 @@ static struct ctl_table nf_ct_netfilter_table[] = {
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = SYSCTL_ZERO,
+ .extra1 = SYSCTL_ONE,
.extra2 = SYSCTL_INT_MAX,
},
};
Undocumented historical behavior inherited from ip_conntrack (ipv4 only ancestor) days. If set to 0, no limit is applied. conntrack table can grow to huge value, only limited by size of conntrack table and the kernel-internal upper limit on the hash chain lengths. This feature makes no sense; users can just set conntrack_max=2147483647 (INT_MAX) if tehy want. Disallow a 0 value. This will make it slightly easier to allow per-netns constraints for this value in a future patch. Signed-off-by: Florian Westphal <fw@strlen.de> --- net/netfilter/nf_conntrack_core.c | 2 +- net/netfilter/nf_conntrack_standalone.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)