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.

Thanks.