From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, Florian Westphal <fw@strlen.de>,
Matthieu Baerts <matttbe@kernel.org>,
netfilter-devel@vger.kernel.org,
Jozsef Kadlecsik <kadlec@netfilter.org>,
coreteam@netfilter.org
Subject: Re: Netfilter: suspicious RCU usage in __nft_rule_lookup
Date: Fri, 25 Oct 2024 12:26:47 +0200 [thread overview]
Message-ID: <ZxtyZ8-jVGuGCU2K@calendula> (raw)
In-Reply-To: <Zxto-TvgUAa1p9N9@orbyte.nwl.cc>
On Fri, Oct 25, 2024 at 11:46:33AM +0200, Phil Sutter wrote:
> On Fri, Oct 25, 2024 at 11:23:56AM +0200, Florian Westphal wrote:
> > Matthieu Baerts <matttbe@kernel.org> wrote:
> > > While at it, I had a question related to the rules' list: in
> > > __nft_release_basechain() from the same nf_tables_api.c file, list's
> > > entries are not removed with the _rcu variant → is it OK to do that
> > > because this function is only called last at the cleanup time, when no
> > > other readers can iterate over the list? So similar to what is done in
> > > __nft_release_table()?
> >
> > Looks like __nft_release_basechain() is broken from start, I don't see
> > how it can work, it doesn't call synchronize_rcu or anything like that
> > afaics.
> >
> > No idea what to do here.
>
> It will vanish with my name-based netdev hooks series (the second part).
> I could prepare a patch for nf/stable which merely kills that function -
> dropping netdev-family chains upon removal of last interface is
> inconsistent wrt. flowtables which remain in place.
I like the idea of keeping the basechain in place. With chain update
support, it makes sense to add a basechain then update it with the
devices to hook in.
But chain device updates are only recently supported:
b9703ed44ffbfba85c103b9de01886a225e14b38
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri Apr 21 00:34:31 2023 +0200
netfilter: nf_tables: support for adding new devices to an existing netdev chain
that is, in older kernels, this chain would remain unused because
updates are not be possible.
> Another alternative might be to call synchronize_rcu() in there, but it
> slows down interface teardown AIUI.
Else unregister objects from lists under mutex then call_rcu() to
release them.
Then, take you patch so new kernel don't remove the basechain.
next prev parent reply other threads:[~2024-10-25 10:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 16:56 Netfilter: suspicious RCU usage in __nft_rule_lookup Matthieu Baerts
2024-10-24 17:35 ` Florian Westphal
2024-10-24 18:00 ` Pablo Neira Ayuso
2024-10-24 17:57 ` Pablo Neira Ayuso
2024-10-24 18:20 ` Pablo Neira Ayuso
2024-10-24 23:22 ` Florian Westphal
2024-10-25 8:14 ` Matthieu Baerts
2024-10-25 9:23 ` Florian Westphal
2024-10-25 9:42 ` Pablo Neira Ayuso
2024-10-25 9:46 ` Phil Sutter
2024-10-25 10:26 ` Pablo Neira Ayuso [this message]
2024-10-25 10:56 ` Phil Sutter
2024-10-25 11:43 ` Pablo Neira Ayuso
2024-10-25 13:16 ` Pablo Neira Ayuso
2024-10-25 10:35 ` 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=ZxtyZ8-jVGuGCU2K@calendula \
--to=pablo@netfilter.org \
--cc=coreteam@netfilter.org \
--cc=fw@strlen.de \
--cc=kadlec@netfilter.org \
--cc=matttbe@kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/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.