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

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.