Re: [PATCH net-next 0/3] net: bridge: add stp_mode attribute for STP mode selection

[Jonas Gorski <jonas.gorski@gmail.com>]

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.

Best regards,
Jonas