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
