From: Ido Schimmel <idosch@nvidia.com>
To: Runyu Xiao <runyu.xiao@seu.edu.cn>
Cc: Nikolay Aleksandrov <razor@blackwall.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
bridge@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, jianhao.xu@seu.edu.cn
Subject: Re: Question: bridge: clarify MST VLAN list RCU traversal contract
Date: Sun, 28 Jun 2026 20:49:00 +0300 [thread overview]
Message-ID: <20260628174900.GA400397@shredder> (raw)
In-Reply-To: <20260627132539.3701630-1-runyu.xiao@seu.edu.cn>
On Sat, Jun 27, 2026 at 09:25:39PM +0800, Runyu Xiao wrote:
> Hi bridge maintainers,
>
> This question comes from a candidate found by our static analysis tool
> and then manually reviewed against the current tree. The audit used
> CONFIG_PROVE_RCU_LIST as target-matched triage evidence; I am asking
> for maintainer guidance because the source-level review did not prove
> a use-after-free.
>
> A CONFIG_PROVE_RCU_LIST audit flags the VLAN-list traversal in
> br_mst_info_size():
>
> net/bridge/br_mst.c:251 br_mst_info_size()
>
> The helper walks vg->vlan_list with list_for_each_entry_rcu(). In the
> direct local context, br_get_link_af_size_filtered() first enters an
> RCU read-side section, resolves the bridge port or bridge VLAN group,
> and calls br_get_num_vlan_infos(vg, filter_mask). That local RCU
> read-side section is then dropped before the later MST sizing call:
>
> net/bridge/br_netlink.c:104 rcu_read_lock()
> net/bridge/br_netlink.c:113 br_get_num_vlan_infos(vg, filter_mask)
> net/bridge/br_netlink.c:114 rcu_read_unlock()
> net/bridge/br_netlink.c:123 br_mst_info_size(vg)
>
> The helper is registered through rtnl_af_ops.get_link_af_size, and
> bridge VLAN updates appear RTNL-centered, so the broader rtnetlink
> sizing path may already provide the intended serialization. I am not
> claiming a use-after-free here. The question is only whether the
> RCU-list traversal contract around br_mst_info_size() should be made
> explicit enough for CONFIG_PROVE_RCU_LIST to see it.
>
> Would you prefer one of these directions?
>
> 1. keep the MST sizing loop inside an explicit rcu_read_lock() in
> br_get_link_af_size_filtered();
>
> 2. pass a confirmed RTNL lockdep condition to the iterator in
> br_mst_info_size();
>
> 3. document that the outer rtnetlink sizing path is the required
> protection and leave the helper unchanged;
>
> 4. use a different bridge-specific pattern.
>
> I am intentionally sending this as a maintainer question rather than a
> patch because the right contract seems to depend on the bridge/rtnetlink
> caller semantics.
I don't think anything needs to change. AFAICT, br_mst_info_size() is
only reachable via the get_link_af_size() callback and
rtnl_link_get_af_size() always invokes it from an RCU read-side critical
section.
Did you see a splat with CONFIG_PROVE_RCU_LIST?
prev parent reply other threads:[~2026-06-28 17:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-27 13:25 Question: bridge: clarify MST VLAN list RCU traversal contract Runyu Xiao
2026-06-28 17:49 ` Ido Schimmel [this message]
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=20260628174900.GA400397@shredder \
--to=idosch@nvidia.com \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jianhao.xu@seu.edu.cn \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=runyu.xiao@seu.edu.cn \
/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.