Re: [PATCH net] net: bridge: don't under-estimate the VLAN tunnel info size

[Ido Schimmel <idosch@nvidia.com>]

On Wed, Oct 07, 2026 at 05:59:37AM +0000, Yiming Qian wrote:
> br_info_notify() sizes the notification skb with br_nlmsg_size() and then
> fills it with br_fill_ifinfo().  If the fill does not fit, br_info_notify()
> does WARN_ON(err == -EMSGSIZE) because that is supposed to mean a bug in
> br_nlmsg_size().
> 
> br_nlmsg_size() (via br_get_link_af_size_filtered() and
> br_get_vlan_tunnel_info_size()) only accounts for the VLANs that have a
> tunnel mapping at that moment, while br_fill_vlan_tunnel_info() emits an
> attribute for every VLAN that has one by the time it runs.  br_info_notify()
> also runs without RTNL (e.g. from br_forward_delay_timer_expired()), so
> tunnel mappings added or removed under RTNL between the size calculation and
> the fill make the fill need more room than was reserved:
> 
>   WARNING: net/bridge/br_netlink.c:660 at br_info_notify+0x13f/0x150
>   ...
>   Call Trace:
>    <IRQ>
>    br_forward_delay_timer_expired+0x1b3/0x1f0
>    call_timer_fn+0x2d/0xd0
>    __run_timer_base+0x5ba/0x7d0
>    run_timer_softirq+0x31/0x60
>    handle_softirqs+0x17f/0x570
>   ...
>   Kernel panic - not syncing: kernel: panic_on_warn set ...
> 
> Size the tunnel info for the maximum number of attributes that
> br_fill_vlan_tunnel_info() can emit for the VLAN group instead of for the
> mappings that are currently installed.  Consecutive VIDs with consecutive
> tunnel IDs are compressed into two attributes, so the fill never emits more
> attributes than there are usable VLANs, which keeps br_nlmsg_size() an upper
> bound of what the fill needs.
> 
> Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support")
> Cc: Yiming Qian <yimingqian591@gmail.com>
> Signed-off-by: Yiming Qian <yimingqian591@gmail.com>

br_info_notify() is inherently racy when called without RTNL. Better to
just remove the WARN_ON() in br_info_notify(). Blaming commit
b7853d73e39b ("bridge: add vlan info to bridge setlink and dellink
notification messages") seems appropriate.

Note: "don’t repost your patches within one 24h period"
https://docs.kernel.org/next/process/maintainer-netdev.html