[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251119222940.GA5070@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Wed, 19 Nov 2025 14:29:40 -0800
From: Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>
To: Phil Sutter <phil@....cc>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
linux-kernel@...r.kernel.org
Subject: Re: Soft lock-ups caused by iptables
On Wed, Nov 19, 2025 at 03:49:57PM +0100, Phil Sutter wrote:
> Nftables ruleset validation code was refactored in v6.10 with commit
> cff3bd012a95 ("netfilter: nf_tables: prefer nft_chain_validate"). This
> is also present in v5.15.184, so in order to estimate whether a bug is
> "new" or "old", better really use old kernels not recent minor releases
> of old major ones. :)
FWIW I tried to repro this on v6.6.45 as well and it also suffers from
this issue.
>
> So, how many --jump/--goto calls does your 40k iptables dump contain? Is
> this a (penetration) test or an actual ruleset in use? While it might be
> possible to reduce the overhead involved with this chain validation,
> maybe you want to consider using ipset (or better, nftables and its
> verdict maps) to improve the ruleset in general?
>
The vast majority of rules have --jumps (see the attached file). My
reproducible setup is a stress test but we have seen something like this
in production as well. Also, I'm not opposed to the idea of trying something
more efficient but I think we should get to the bottom of what's going on
here.
BR,
Hamza
Download attachment "iptables-save.gz" of type "application/gzip" (404920 bytes)
Powered by blists - more mailing lists