From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Chris Arges <carges@cloudflare.com>
Cc: netfilter-devel@vger.kernel.org, fw@strlen.de
Subject: Re: [PATCH nf,v2] netfilter: nft_set_rbtree: allocate same array size on updates
Date: Wed, 11 Mar 2026 17:43:27 +0100 [thread overview]
Message-ID: <abGbr0xbcAvRDMUZ@chamomile> (raw)
In-Reply-To: <abGYhwlvCWKoKNmm@20HS2G4>
On Wed, Mar 11, 2026 at 11:29:59AM -0500, Chris Arges wrote:
> On 2026-03-07 01:11:24, Pablo Neira Ayuso wrote:
> > The array resize function increments the size of the array in
> > NFT_ARRAY_EXTRA_SIZE slots for each update, this is unnecesarily
> > increasing the array size.
> >
> > To determine the number of array slots:
> >
> > - Use NFT_ARRAY_EXTRA_SIZE for new sets.
> > - Use the current maximum number of intervals in the live array.
> >
> > Reported-by: Chris Arges <carges@cloudflare.com>
> > Fixes: 7e43e0a1141d ("netfilter: nft_set_rbtree: translate rbtree to array for binary search")
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> > ---
> > v2: fix crash with new sets, reported by Florian.
> >
> > net/netfilter/nft_set_rbtree.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
>
> Pablo,
Chris,
> I was able to test with this patch applied on top of v6.18.16; however the
> memory consumption remained high and similar to v6.18.16 without this patch.
Makes no sense to me.
> My VM reproducer runs the services and checks for slab memory increases. In a
> passing test case, the unreclaimable slab memory reaches about 1.4G and
> stabilizes. In a failure test case unreclaimable slab memory goes beyond 4.4G
> then the process gets OOM killed due to cgroup memory limits.
I have to review again what I posted. You mean, memory keeps for each
dynamic update, increasing until it reaches OOM?
> Also, using this reproducer I re-verified that this patch is what changes
> slab memory.stat characteristics from within the cgroup:
> - 7e43e0a1141d netfilter: nft_set_rbtree: translate rbtree to array for binary search
>
> Finally, I reverted the following patches from v6.18.16 and re-tested using my
> reproducer:
> - 648946966a08 netfilter: nft_set_rbtree: validate open interval overlap
> - 782f2688128e netfilter: nft_set_rbtree: validate element belonging to interval
> - 35f83a75529a netfilter: nft_set_rbtree: don't gc elements on insert
Are you using timeout in your set?
> - 5599fa810b50 netfilter: nft_set_rbtree: remove seqcount_rwlock_t
> - 2aa34191f06f netfilter: nft_set_rbtree: use binary search array in get command
> - 7e43e0a1141d netfilter: nft_set_rbtree: translate rbtree to array for binary search
> In this instance memory allocations were again around 1.4G.
>
> Any suggestions for other tests, I can rebuild with memory debugging config as
> well.
>
> Also, could there be an option here to opt-out of this performance optimization
> in favor of retaining existing memory characteristics?
This series is fixing a real bug, now you may experience possible
false negatives in lookups with what you have reverted.
I am going to collect memory numbers and post them here, I will try to
mimic a script from your description.
next prev parent reply other threads:[~2026-03-11 16:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 0:11 [PATCH nf,v2] netfilter: nft_set_rbtree: allocate same array size on updates Pablo Neira Ayuso
2026-03-07 9:07 ` Florian Westphal
2026-03-07 12:59 ` Pablo Neira Ayuso
2026-03-07 13:06 ` Florian Westphal
2026-03-08 10:47 ` Pablo Neira Ayuso
2026-03-11 16:29 ` Chris Arges
2026-03-11 16:43 ` Pablo Neira Ayuso [this message]
2026-03-11 18:45 ` Chris Arges
-- strict thread matches above, loose matches on Subject: below --
2026-03-08 11:23 Pablo Neira Ayuso
2026-03-08 11:25 ` Pablo Neira Ayuso
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=abGbr0xbcAvRDMUZ@chamomile \
--to=pablo@netfilter.org \
--cc=carges@cloudflare.com \
--cc=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