From: netdev-bot+sashiko@kernel.org
To: teel4res@gmail.com
Cc: razor@blackwall.org, idosch@nvidia.com, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, bridge@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, tobias@waldekranz.com
Subject: Re: [PATCH net] net: bridge: do not bypass port state for MST without VLAN filtering
Date: Mon, 26 Oct 2026 15:29:05 +0000 [thread overview]
Message-ID: <179302854528.3134.18358959701165767967@kernel.org> (raw)
In-Reply-To: <179268538303.70821.3493915601694605045@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.
Critical: 0 · High: 0 · Medium: 1 · Low: 0
If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).
- [Medium] The patch adds a live, lockless read of BROPT_VLAN_ENABLED to
br_mst_is_enabled() (net/bridge/br_private.h:1956).
--
net: bridge: do not bypass port state for MST without VLAN filtering
This commit makes br_mst_is_enabled() also require BROPT_VLAN_ENABLED.
Without that check, a bridge with MST enabled but VLAN filtering
disabled enforces no port state at all. With the patch, the legacy STP
port state checks apply until VLAN filtering is turned on.
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index ff746f036f548..85065304597eb 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -1953,6 +1953,7 @@ static inline bool br_mst_is_enabled(const struct net_bridge_port *p)
> /* check the port's vlan group to avoid racing with port deletion */
> return static_branch_unlikely(&br_mst_used) &&
> br_opt_get(p->br, BROPT_MST_ENABLED) &&
> + br_opt_get(p->br, BROPT_VLAN_ENABLED) &&
> rcu_access_pointer(p->vlgrp);
> }
[Severity: Medium]
Can a frame now skip both the legacy port state check and the per-VLAN
MST state check while vlan_filtering is being toggled?
The predicate now depends on a bit that can change at runtime. A single
frame evaluates it separately in br_handle_frame(),
br_handle_frame_finish() and should_deliver(). br_allowed_ingress() also
reads BROPT_VLAN_ENABLED on its own. The writer flips the bit under RTNL
and does not wait for frames already in flight:
net/bridge/br_vlan.c:br_vlan_filter_toggle() {
...
br_opt_toggle(br, BROPT_VLAN_ENABLED, !!val);
err = switchdev_port_attr_set(br->dev, &attr, extack);
if (err && err != -EOPNOTSUPP) {
br_opt_toggle(br, BROPT_VLAN_ENABLED, !val);
return err;
}
...
}
Say VLAN filtering is being turned off while MST is enabled, and the
ingress port is in BR_STATE_BLOCKING. Here is one interleaving:
br_handle_frame()
if (br_mst_is_enabled(p)) <-- true
goto defer_stp_filtering; <-- BLOCKING drop skipped
nf_hook_bridge_pre() <-- frame may sit in NF_QUEUE
br_vlan_filter_toggle() clears
BROPT_VLAN_ENABLED
br_handle_frame_finish()
if (br_mst_is_enabled(p)) { <-- now false
} else {
if (p->state == BR_STATE_DISABLED) <-- only DISABLED dropped
state = p->state; <-- BLOCKING
}
br_allowed_ingress() <-- returns true, filtering off
if (state == BR_STATE_LEARNING) <-- only remaining state check
The frame then looks like it is forwarded or flooded from a BLOCKING
port.
A similar case is when both MST checks see true and set state to
BR_STATE_FORWARDING, and the bit is cleared before br_allowed_ingress()
runs. In that case the per-VLAN MST state is never applied either.
On egress, when VLAN filtering is being turned on, ingress can record
vlan_filtered = false. should_deliver() then sees br_mst_is_enabled()
as true and skips the p->state check:
(br_mst_is_enabled(p) || p->state == BR_STATE_FORWARDING) &&
br_allowed_egress(vg, skb) && ...
br_allowed_egress() then passes the frame unconditionally:
if (!BR_INPUT_SKB_CB(skb)->vlan_filtered)
return true;
Would that let a BLOCKING egress port transmit the frame?
Before this patch, br_mst_is_enabled() did not depend on
BROPT_VLAN_ENABLED, so these interleavings look new. The window only
lasts while the reads disagree. A bridge PREROUTING NF_QUEUE rule can
stretch it.
Would it be possible to make the MST/VLAN decision once per frame and
reuse it at each check? For example, it could be carried in
BR_INPUT_SKB_CB. Another option is to skip p->state in should_deliver()
only when BR_INPUT_SKB_CB(skb)->vlan_filtered is set. A third is to
re-check BLOCKING/LISTENING in br_handle_frame_finish() when VLAN
filtering turns out to be off.
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/179268538303.70821.3493915601694605045%40gmail.com
prev parent reply other threads:[~2026-10-26 15:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 15:26 Cheng Yongkang
2026-10-22 16:13 ` netdev-bot+sinfo
2026-10-23 8:47 ` Tobias Waldekranz
2026-10-23 9:57 ` Nikolay Aleksandrov
2026-10-26 15:29 ` netdev-bot+sashiko [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=179302854528.3134.18358959701165767967@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=teel4res@gmail.com \
--cc=tobias@waldekranz.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®