From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F1E1355049 for ; Wed, 25 Mar 2026 07:28:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774423713; cv=none; b=Uh5R+tTSaXWn/X2+9uTLfPeDym53gHbyP78PPzPbd+o1r9ZnUkHJssg/GuA75WbgOqUbfKM3yt+tcRzWvGuplJVPZEwI3Kalxh46wOGXeOkcg9oSXooxwh7ZMWFv+g46Ud396e0dRX7xhTHIxv9z7OvH/MTKvyCBiVQ5KQXC0PI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774423713; c=relaxed/simple; bh=S/BaYDdPcQXTkL2SnY6Z59AFoydNh1oEXzUXxXeESmU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kPcpXT2tOne3+5JF+P9YYtbP/23XVDON2ssv5vYx06QYzNXc6brudZq5AkdTHK3Cq+RtuilAHGhUeBQPfo07W5Ni1EAGDG2VO7tKvY3iPBzkm9xv8PISO8+uBLBkhbEU2QSD4F8Ot9PGJOV5ZAortLpodNRI1MAFS1LP1i0vmjE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=R8Pfbuyn; arc=none smtp.client-ip=209.85.218.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="R8Pfbuyn" Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-b982b0889d8so294720566b.2 for ; Wed, 25 Mar 2026 00:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774423711; x=1775028511; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xXcLoA3AOm8JsZyBFRvvn/2aLGbl2SRuVxCEIFV1m/A=; b=R8Pfbuynzy68urWZLJkASnZ3+9kYqcCyt/sSj3Ubahjjffw0/05utO4gY5/m8JhhCi t6wzAew/HBmrScLgU9X519rEOBW7kSP6Rt8hXWGCKRTdgj8tOjvyNPTtcAaMN8NYvLUY 3M3NVD27n1r8tf/eGAiiLEh8xkEoIyeEQ3vOnBJfE9EGnlCn+F+2nxgBEbS4sVIxJ1XN 1fZHjbVQYzAOijX2P4G6BRK1hBUnpkhJ3bIz1xwcgQqPSSQgYge79AX9meLht2uh03zu k/pl3n8IfJE2w9lc21mkNL1qApCqMiK78c//Kgz13gdIbRjuw+QNLTm3ELxR17emZBOK jUyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774423711; x=1775028511; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xXcLoA3AOm8JsZyBFRvvn/2aLGbl2SRuVxCEIFV1m/A=; b=SYuMX+XQIcLn4uhcwVe8e7r2J7VOhsAi3hfAkGw247vDR/2J31sf9desMxCDFanXWz EkQfrVwH01GpIMJYugyooMmvTDebQAULXrk1k4lCDlqah6uI1UYu9hT8k4IEYn7wizvL NZ2E5GiCo8cg55sTmSbjcH3f9o67uxJEmdD7aDc23fuLkjhHCmo70d2Vk2enO7AHec4Q 3domAhcWtTYfipt04CzWGJwZQJ2mc/EKs6rF57f3x4w5vQT+4sjobONltVkYE/xblR/p 7Zpot0AR8A0xW0sMxp5/ELj/ZMXxJNUUCSW5AZnBFED78jrfmFWj7UN6WK3CJxLoh8xo Cm2g== X-Forwarded-Encrypted: i=1; AJvYcCXe9X4PJ62k6nH+Wzmna9HijWvvc2l1vvJRyNaYDnu0vKhGKxnDUY+Yfih5PhR4rxuHGia3gQsz5ghB+9U=@vger.kernel.org X-Gm-Message-State: AOJu0YyKRoP2vvRY6NCENaC+TXZXBgcQ10heHxLG7jHlR493HtaHrN7Y Bi488Iq0VqP9TNca0FxCBhG1HQFDZxvIJDK0chT0RytieN3R871C/sC1 X-Gm-Gg: ATEYQzzMzt/Q4OD/72r6plsDwZMOey3ieO+WVeMsxyAKdfQPOiJPaNA/6BPEPScjRgF sRhwnRVDeV5mv5z81he6bSyReRWPTcXdZNQ1tq8nlmk6kWXO0LXrgtfV99UUE1n30uRDhfl2FPH LSFDq8LAMqRe0FiH7XUgXGFzK3LoPLzj6GVS1Eyx1mcCijed/KxBtLPt/U7oQPDVyT6sjATfs/F bgHHqAcYgA4brOwIQFIHYUdQUMQBBcpugNoEeFJPuM7DB6/bcfpOj7w1ZuBiN82OvW++lfuIoHu kCpFCTRq+YDXx/chIC/iK+aXvuGWl++uWWbGDIOxAFhmoeU4P2w2h4ho0x8Vd2pMVJnMQZSPQCb uMxvBtgIOk6H+LlzgxGA6DydrmuEkslceumCHxOfgXfYMMgacKp1KRaodcy350w/pTiFG6SRZY0 +RuIh4AWCG2B7jtS1m8ZujOG8hmxAfL9domxOY98oKZ9cjAc3OA/oytfTh116/v0FqfB5IVnaYj 15z7LVMKx2v X-Received: by 2002:a17:907:d1c:b0:b98:6c41:a77f with SMTP id a640c23a62f3a-b9a3f1a815dmr138126866b.20.1774423710456; Wed, 25 Mar 2026 00:28:30 -0700 (PDT) Received: from [192.168.0.2] (dslb-002-205-018-238.002.205.pools.vodafone-ip.de. [2.205.18.238]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b984b056f3bsm573597266b.26.2026.03.25.00.28.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Mar 2026 00:28:29 -0700 (PDT) Message-ID: Date: Wed, 25 Mar 2026 08:28:28 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 0/3] net: bridge: add stp_mode attribute for STP mode selection To: Andy Roulin , netdev@vger.kernel.org Cc: bridge@lists.linux.dev, Nikolay Aleksandrov , Ido Schimmel , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan , Petr Machata , linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260324184942.2828691-1-aroulin@nvidia.com> Content-Language: en-US From: Jonas Gorski In-Reply-To: <20260324184942.2828691-1-aroulin@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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