From: Pablo Neira Ayuso <pablo@netfilter.org>
To: netfilter-devel@vger.kernel.org
Cc: davem@davemloft.net, netdev@vger.kernel.org, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com, fw@strlen.de,
kadlec@netfilter.org
Subject: [PATCH net-next 3/4] netfilter: xt_hashlimit: htable_selective_cleanup() optimization
Date: Sun, 12 Jan 2025 00:07:59 +0100 [thread overview]
Message-ID: <20250111230800.67349-4-pablo@netfilter.org> (raw)
In-Reply-To: <20250111230800.67349-1-pablo@netfilter.org>
From: Eric Dumazet <edumazet@google.com>
I have seen syzbot reports hinting at xt_hashlimit abuse:
[ 105.783066][ T4331] xt_hashlimit: max too large, truncated to 1048576
[ 105.811405][ T4331] xt_hashlimit: size too large, truncated to 1048576
And worker threads using up to 1 second per htable_selective_cleanup() invocation.
[ 269.734496][ C1] [<ffffffff81547180>] ? __local_bh_enable_ip+0x1a0/0x1a0
[ 269.734513][ C1] [<ffffffff817d75d0>] ? lockdep_hardirqs_on_prepare+0x740/0x740
[ 269.734533][ C1] [<ffffffff852e71ff>] ? htable_selective_cleanup+0x25f/0x310
[ 269.734549][ C1] [<ffffffff817dcd30>] ? __lock_acquire+0x2060/0x2060
[ 269.734567][ C1] [<ffffffff817f058a>] ? do_raw_spin_lock+0x14a/0x370
[ 269.734583][ C1] [<ffffffff852e71ff>] ? htable_selective_cleanup+0x25f/0x310
[ 269.734599][ C1] [<ffffffff81547147>] __local_bh_enable_ip+0x167/0x1a0
[ 269.734616][ C1] [<ffffffff81546fe0>] ? _local_bh_enable+0xa0/0xa0
[ 269.734634][ C1] [<ffffffff852e71ff>] ? htable_selective_cleanup+0x25f/0x310
[ 269.734651][ C1] [<ffffffff852e71ff>] htable_selective_cleanup+0x25f/0x310
[ 269.734670][ C1] [<ffffffff815b3cc9>] ? process_one_work+0x7a9/0x1170
[ 269.734685][ C1] [<ffffffff852e57db>] htable_gc+0x1b/0xa0
[ 269.734700][ C1] [<ffffffff815b3cc9>] ? process_one_work+0x7a9/0x1170
[ 269.734714][ C1] [<ffffffff815b3dc9>] process_one_work+0x8a9/0x1170
[ 269.734733][ C1] [<ffffffff815b3520>] ? worker_detach_from_pool+0x260/0x260
[ 269.734749][ C1] [<ffffffff810201c7>] ? _raw_spin_lock_irq+0xb7/0xf0
[ 269.734763][ C1] [<ffffffff81020110>] ? _raw_spin_lock_irqsave+0x100/0x100
[ 269.734777][ C1] [<ffffffff8159d3df>] ? wq_worker_sleeping+0x5f/0x270
[ 269.734800][ C1] [<ffffffff815b53c7>] worker_thread+0xa47/0x1200
[ 269.734815][ C1] [<ffffffff81020010>] ? _raw_spin_lock+0x40/0x40
[ 269.734835][ C1] [<ffffffff815c9f2a>] kthread+0x25a/0x2e0
[ 269.734853][ C1] [<ffffffff815b4980>] ? worker_clr_flags+0x190/0x190
[ 269.734866][ C1] [<ffffffff815c9cd0>] ? kthread_blkcg+0xd0/0xd0
[ 269.734885][ C1] [<ffffffff81027b1a>] ret_from_fork+0x3a/0x50
We can skip over empty buckets, avoiding the lockdep penalty
for debug kernels, and avoid atomic operations on non debug ones.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_hashlimit.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 0859b8f76764..fa02aab56724 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -363,11 +363,15 @@ static void htable_selective_cleanup(struct xt_hashlimit_htable *ht, bool select
unsigned int i;
for (i = 0; i < ht->cfg.size; i++) {
+ struct hlist_head *head = &ht->hash[i];
struct dsthash_ent *dh;
struct hlist_node *n;
+ if (hlist_empty(head))
+ continue;
+
spin_lock_bh(&ht->lock);
- hlist_for_each_entry_safe(dh, n, &ht->hash[i], node) {
+ hlist_for_each_entry_safe(dh, n, head, node) {
if (time_after_eq(jiffies, dh->expires) || select_all)
dsthash_free(ht, dh);
}
--
2.30.2
next prev parent reply other threads:[~2025-01-11 23:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-11 23:07 [PATCH net-next 0/4] Netfilter/IPVS updates for net-next Pablo Neira Ayuso
2025-01-11 23:07 ` [PATCH net-next 1/4] netfilter: nf_tables: remove the genmask parameter Pablo Neira Ayuso
2025-01-14 11:20 ` patchwork-bot+netdevbpf
2025-01-11 23:07 ` [PATCH net-next 2/4] ipvs: speed up reads from ip_vs_conn proc file Pablo Neira Ayuso
2025-01-11 23:07 ` Pablo Neira Ayuso [this message]
2025-01-11 23:08 ` [PATCH net-next 4/4] netfilter: conntrack: add conntrack event timestamp 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=20250111230800.67349-4-pablo@netfilter.org \
--to=pablo@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.