From: Florian Westphal <fw@strlen.de>
To: Ren Wei <n05ec@lzu.edu.cn>
Cc: netfilter-devel@vger.kernel.org, bridge@lists.linux.dev,
pablo@netfilter.org, phil@nwl.cc, razor@blackwall.org,
idosch@nvidia.com, stephen@networkplumber.org,
sw@simonwunderlich.de, davem@davemloft.net, yuantan098@gmail.com,
yifanwucs@gmail.com, tomapufckgml@gmail.com, bird@lzu.edu.cn,
royenheart@gmail.com
Subject: Re: [PATCH nf v2 1/1] bridge: br_netfilter: move fake rtable off struct net_bridge
Date: Wed, 27 May 2026 09:42:03 +0200 [thread overview]
Message-ID: <ahagS3rGl2sG0OVS@strlen.de> (raw)
In-Reply-To: <831936f111e6e1f435f4f6247d07fe6a6624d271.1779680014.git.royenheart@gmail.com>
Ren Wei <n05ec@lzu.edu.cn> wrote:
> From: Haoze Xie <royenheart@gmail.com>
>
> The bridge netfilter fake rtable currently lives inside struct
> net_bridge and is reattached to bridged packets with
> skb_dst_set_noref(). If such a packet is queued to NFQUEUE,
> __nf_queue() upgrades that fake dst with skb_dst_force().
>
> At that point queued packets can hold a real dst reference even after
> bridge teardown starts freeing the backing struct net_bridge storage.
> When verdict reinjection later drops the skb, dst_release() can hit the
> freed bridge-private fake rtable.
>
> Fix this by moving the fake rtable out of struct net_bridge and making
> bridge_parent_rtable() hand out a referenced dst. This keeps the queued
> skb path from holding a pointer into struct net_bridge while keeping the
> kludge local to br_netfilter.
>
> Use rt_dst_alloc() so the fake dst reuses the core IPv4 rtable
> lifecycle, and release the bridge device reference during teardown via
> dst_dev_put() before dropping the bridge-owned dst reference.
I think AI review is mostly correct:
https://sashiko.dev/#/patchset/831936f111e6e1f435f4f6247d07fe6a6624d271.1779680014.git.royenheart%40gmail.com
- no need for constant refcount bump
- I don't think the ipv4 specific functions can be used safely here.
next prev parent reply other threads:[~2026-05-27 7:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 3:21 [PATCH nf v2 1/1] bridge: br_netfilter: move fake rtable off struct net_bridge Ren Wei
2026-05-27 7:42 ` Florian Westphal [this message]
2026-06-03 23:40 ` Florian Westphal
2026-06-04 1:52 ` Haoze Xie
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=ahagS3rGl2sG0OVS@strlen.de \
--to=fw@strlen.de \
--cc=bird@lzu.edu.cn \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=idosch@nvidia.com \
--cc=n05ec@lzu.edu.cn \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=razor@blackwall.org \
--cc=royenheart@gmail.com \
--cc=stephen@networkplumber.org \
--cc=sw@simonwunderlich.de \
--cc=tomapufckgml@gmail.com \
--cc=yifanwucs@gmail.com \
--cc=yuantan098@gmail.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.