From: Florian Westphal <fw@strlen.de>
To: netfilter-devel@vger.kernel.org
Subject: conntrack extension preallocation problems
Date: Thu, 24 Sep 2026 12:46:16 +0200 [thread overview]
Message-ID: <arT_eE_oV2ZEx-Zm@strlen.de> (raw)
TL;DR: simple prellocation is not possible, it will result in at least
192 bytes ct->ext allocation for most use-cases which is hardly
desirable.
Following extensions exist in tree:
Extension |size| activation
---------------------------------------------
struct nf_conn_act_ct_ext | 8 | act_ct/ovs only, could be converted to template
struct nf_conn_acct | 32 | sysctl only
struct nf_conn_labels | 16 | ruleset (sysctl-like)
struct nf_conn_seqadj | 24 | dependency of helper and synproxy
struct nf_conn_synproxy | 16 | template
struct nf_conn_timeout | 8 | template OR nft_ct objref
struct nf_conn_tstamp | 16 | sysctl
struct nf_conntrack_ecache| 32 | sysctl or template or nft_ct
struct nf_conn_nat | 8 | nft_masq/MASQUERADE/PPTP helper
struct nf_conn_help | 56 | expectation / template / nft_ct objref
(ct helper set X, ct expectation set)
Simple extensions are all those that get enabled based on sysctl
setting or template. For those init_conntrack() will know they are
going to be added anyway. This is true for:
struct nf_conn_acct | 32
struct nf_conn_labels | 16
struct nf_conn_synproxy | 16
struct nf_conn_tstamp | 16
80 bytes
Almost-Trivial: could convert to template with a bit of refactoring, no
backwards compat issues / breakage that I can see:
struct nf_conn_act_ct_ext | 8
The remaining extensions are all problematic, I can't find any other
solution other than "speculative preallocation if used in ruleset" (can
be pernet):
Extension |size| problematic case
-----------------------------------------------------------------------
struct nf_conn_seqadj | 24 | depends on helper resp. synproxy
struct nf_conn_timeout | 8 | nft_ct objref
struct nf_conntrack_ecache| 32 | nft_ct expr
struct nf_conn_nat | 8 | masq/-j MASQUERADE or PPTP helper
struct nf_conn_help | 56 | nft_ct objref (ct helper set X) nft_ct expr (ct expectation set)
128 bytes total, this means kmalloc-192 (due to ext header size).
NAT: single rule (-j MASQUERADE or rule add ... masq) forces this
extension to on for all.
NAT: PPTP helper existence also needs this as dependency
ecache: single "ct event set .." is enough to force prealloc for all.
help: same, single "ct expectation set", "ct helper set " is enough.
timeout: same, via "ct timeout set ...".
seqadj: required when "help" extension is used.
I cannot come up with a (backwards compatible) solution for these
so far (aside from preallocating them all on first rule add).
Even if we would decide to break existing setups, nft_ct is hard to solve,
we would have to make this "-j CT" alike, where all required extensions
are passed in one go to a single objref instance.
"ct helper set" is definitely the worst offender:
While most conntracks do not need the helper extension in normal
deployments, we would add the extra baggage for every conntrack.
I think we have to consider going back to old times, i.e. rcu protected
ext storage, plus additional locking to cope with the "cloned unconfirmed
conntracks" offenders, at least for sake of these remaining 5 extensions,
else we end up allocating large ct->ext whenever a single conntrack
helper is used...
Unless anyone has a better idea, I will work on this, i.e.:
- prealloc for trivial cases (sysctl and/or attached template)
- prealloc for "let's assume most will need it" (masquerade)
- realloc for all others: helper/seqadj and the existing nft_ct
use cases.
Because of "clone problem" realloc will become more expensive:
lock + rcu + dealing with list_head move inside helper area.
reply other threads:[~2026-09-24 10:46 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arT_eE_oV2ZEx-Zm@strlen.de \
--to=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox