From: Andy Roulin <aroulin@nvidia.com>
To: Jonas Gorski <jonas.gorski@gmail.com>, netdev@vger.kernel.org
Cc: bridge@lists.linux.dev, Nikolay Aleksandrov <razor@blackwall.org>,
Ido Schimmel <idosch@nvidia.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"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>, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <shuah@kernel.org>, Petr Machata <petrm@nvidia.com>,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 0/3] net: bridge: add stp_mode attribute for STP mode selection
Date: Wed, 25 Mar 2026 13:12:08 -0700 [thread overview]
Message-ID: <27376c12-33d7-4da2-acc8-dd42aa347e64@nvidia.com> (raw)
In-Reply-To: <abb8a10c-571e-44f2-a15e-1d5da288963d@gmail.com>
On 3/25/26 00:28, Jonas Gorski wrote:
> On 24/03/2026 19:49, Andy Roulin wrote:
>> The bridge-stp usermode helper is currently restricted to the initial
>> network namespace, preventing userspace STP daemons like mstpd from
>> operating on bridges in other namespaces. Since commit ff62198553e4
>> ("bridge: Only call /sbin/bridge-stp for the initial network
>> namespace"), bridges in non-init namespaces silently fall back to
>> kernel STP with no way to request userspace STP.
>>
>> This series adds a new IFLA_BR_STP_MODE bridge attribute that allows
>> explicit per-bridge control over STP mode selection. Three modes are
>> supported:
>>
>> - auto (default): existing behavior, try /sbin/bridge-stp in
>> init_net, fall back to kernel STP otherwise
>> - user: directly enable BR_USER_STP without invoking the helper,
>> works in any network namespace
>> - kernel: directly enable BR_KERNEL_STP without invoking the helper
>
> I like that very much! This will also allow selftests for
> switchdev/dsa drivers for correct (mst) STP state (change) handling.
>
>> The user and kernel modes bypass call_usermodehelper() entirely,
>> addressing the security concerns discussed at [1]. The caller is
>> responsible for managing the userspace STP daemon directly, rather
>> than relying on the kernel to invoke /sbin/bridge-stp.
>
> Should the caller directly manage the STP daemon, or could the STP
> daemon also just automatically manage bridges with
> IFLA_BR_STP_STATE=BR_STP_MODE_KERNEL (and IFLA_BR_STP_STATE != 0)?
>
> The latter would require less changes for network managers, as they
> wouldn't need to be aware of (individual) STP daemon
> implementations.
>
> But I guess either is fine, as long as the latter behavior
> configurable.
STP daemons can listen to netlink and automatically discover the bridges
with IFLA_BR_STP_STATE=BR_STP_MODE_USER (or stp_state=BR_STP_USER).
Will change uapi doc in v2 from
The caller is responsible for registering the bridge with the
userspace STP daemon after enabling STP, and for deregistering it
before disabling STP.
to
No /sbin/bridge-stp helper is invoked; userspace is responsible for
ensuring an STP daemon manages the bridge.
prev parent reply other threads:[~2026-03-25 20:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 18:49 [PATCH net-next 0/3] net: bridge: add stp_mode attribute for STP mode selection Andy Roulin
2026-03-24 18:49 ` [PATCH net-next 1/3] " Andy Roulin
2026-03-24 20:00 ` Ido Schimmel
2026-03-25 7:46 ` Nikolay Aleksandrov
2026-03-24 18:49 ` [PATCH net-next 2/3] docs: net: bridge: document stp_mode attribute Andy Roulin
2026-03-24 18:49 ` [PATCH net-next 3/3] selftests: net: add bridge STP mode selection test Andy Roulin
2026-03-25 7:28 ` [PATCH net-next 0/3] net: bridge: add stp_mode attribute for STP mode selection Jonas Gorski
2026-03-25 20:12 ` Andy Roulin [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=27376c12-33d7-4da2-acc8-dd42aa347e64@nvidia.com \
--to=aroulin@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=bridge@lists.linux.dev \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=jonas.gorski@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=razor@blackwall.org \
--cc=shuah@kernel.org \
/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