From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (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 677102777EA for ; Wed, 25 Mar 2026 07:28:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774423713; cv=none; b=Qsqr6Zw5OmmCSZDv0Hltz4lhMY015oT3Xfh+1twemBiHug4OJeLDtSQenH3uVZ2moRojH0LWSXbu9fbXbeUZz8XuLKSao5GUylyzPsg0jziTdAGxlvDoD3a7dXHqBu3+LwX1fBikgDXDWPeDoV+EydTmSC3G0fi6mHSktfaJMr0= 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.53 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-f53.google.com with SMTP id a640c23a62f3a-b9358bc9c50so323520166b.1 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=ZjWTxi59yw9jJkPCaLvqBInrRqepEXx6TN91RZSafLlePRhvyi+REq3jzUIHfglZgb zXZwK3xiKIUyOUUgXQU3UWgwUrhOv+z6aOKsqGkxr0889SnqC/nnfDvDIYVn+PbdJfT2 4W8kSE7oR6ZOIWQ8HYjcT6zixjFmTYa7Wn5lsTnX9G7+featxGbsAiEsLW+MToly14Sv BypLUMmKNBKKFrU3d27+SxkZm3aUCvhszd3j1u9KrIQvRaLri4RUajzB1CxDtY8QOYOw +6UilUmZo6daAZALbgfsltNOqZjt750L6/DhKVtTHsMByfYvIQGXs5aE+1CGoC06b1pw sRmA== X-Forwarded-Encrypted: i=1; AJvYcCUumWAdwlHIwMwVRmh7sxf1EQJNqyddDc9jGjv9N0EzhLO6sPP4MImhiFRMC0Q/MgicG5OWxzGH/2o=@vger.kernel.org X-Gm-Message-State: AOJu0YyTFp8nnO0OIOQmdQ/L+girXG25x/ZXTHhcfyt49Xng7S7eADLx qZDQfq/KrmVNiAT3xbHuH3+jfDKf2ItNbdXu3SIVxxch+4Ekf62ZPDw2 X-Gm-Gg: ATEYQzxai7t+tQ4A47QY/eCIqmI3WN2PTyrRfs1ESUWtWDJO7hr63YGqoAWOGPpJOu9 ZbLzrPhYiYGnHkYnmOLrgDE6mZit/sLuLts0aaS4wmkymYPBUiWWJaZVI4IURBx8/OgPzMOewAX nsGDpD/tzgreFs38IjJFEUjyLRwgpjijFI4lBLaC9gMLZxLnDIbfXogmDO7jGkE4DnGSzFOhU73 RWOh0G8U5cxb9BMzbBEcBg7tDyHjN25NRPSF27elVovtK+saaFcQJq5mPrDyEjhfWiReQC7M9se nm3mHALsXiNrcL8sPFglURT2QTUjB7gzxDXP0iOT9HvzIGk23N3eHfQW38aeNkYBN9aLLe0yqGG AYZ1deZiijpQ8joUWSfrOUM2h/36H4K0U+oka2xzSGvP3/+D1uBJQoYNlsqILBXHO9lBXiBpdbL pHM0ZVwYV2hwn9x4Ga9iYuC72Ny71u5SPLQJkjctUZSOjta3naWc4ZPn41BfMYxoa1YJnf5TfL/ DeWY389eXDd 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-doc@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