From: Florian Westphal <fw@strlen.de>
To: Brian Witte <brianwitte@mailfence.com>
Cc: kadlec@blackhole.kfki.hu, netfilter-devel@vger.kernel.org,
pablo@netfilter.org
Subject: Re: [PATCH nf-next] netfilter: nf_tables: use dedicated mutex for reset operations
Date: Fri, 30 Jan 2026 12:51:24 +0100 [thread overview]
Message-ID: <aXybPOcqHlBAdwM_@strlen.de> (raw)
In-Reply-To: <20260130015617.42025-1-brianwitte@mailfence.com>
Brian Witte <brianwitte@mailfence.com> wrote:
> Florian Westphal <fw@strlen.de> wrote:
> > Maybe its worth investigating if we should instead protect
> > only the reset action itself, i.e. add private reset spinlocks
> > in nft_quota_do_dump() et al?
>
> Thanks for the suggestion. Implemented per-object spinlocks as proposed.
> Sending inline rather than v2 since I'm not certain about the approach.
>
> Ran tests/shell/run-tests.sh with PROVE_LOCKING, PROVE_RCU, and
> PROVE_RCU_LIST enabled - no warnings.
>
> Uses static lock class keys to avoid lockdep exhaustion with many objects.
>
> Two questions:
>
> 1. Should this be spin_lock_bh()? I think plain spin_lock() is fine
> since the packet path doesn't take this lock.
Its fine if we're interrupted while holding this lock, no (soft)irq
grabs it.
> 2. The nf_tables_api.c changes also remove the try_module_get/module_put
> and rcu_read_unlock/rcu_read_lock dance - that was only needed because
> mutex_lock can sleep and we couldn't hold RCU across it. Since
> spin_lock doesn't sleep, we stay under RCU the entire time. Please
> confirm this is correct.
Yes, this dance isn't needed anymore.
> diff --git a/net/netfilter/nft_counter.c b/net/netfilter/nft_counter.c
> index cc7325329496..ae3c339cbcee 100644
> --- a/net/netfilter/nft_counter.c
> +++ b/net/netfilter/nft_counter.c
> @@ -28,10 +28,13 @@ struct nft_counter_tot {
>
> struct nft_counter_percpu_priv {
> struct nft_counter __percpu *counter;
> + spinlock_t reset_lock; /* protects concurrent reset */
> };
I don't think we need per-object granularity;
a single spinlock in nft_pernet area is enough for this.
next prev parent reply other threads:[~2026-01-30 11:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 3:06 [PATCH nf-next] netfilter: nf_tables: use dedicated mutex for reset operations Brian Witte
2026-01-28 0:09 ` Florian Westphal
2026-01-30 1:56 ` Brian Witte
2026-01-30 11:51 ` Florian Westphal [this message]
2026-02-02 23:01 ` Pablo Neira Ayuso
2026-02-02 23:06 ` Florian Westphal
2026-02-02 23:43 ` 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=aXybPOcqHlBAdwM_@strlen.de \
--to=fw@strlen.de \
--cc=brianwitte@mailfence.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 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.