public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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.

      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