From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 D9CB633A6F1 for ; Mon, 18 May 2026 14:59:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779116391; cv=none; b=ihesmxZJk2tx+ldWtxVAF3E5oy23dzhXzxtdVZt72NdVVaAyLQdnmVTcOWrknM/AAGOez38Aq3/uokf4RhU7dhHziAHnxJhFW3Rl5CzrvQumyhhSBZROT21hYGosAB7rRBI2cGYoXxlPqVx08M2+ij0jwJn+MiZQF/FJ+xuXUBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779116391; c=relaxed/simple; bh=q5XjFVsg+wspXS1sy3GAW2RwWv7+/Bq5enFbkQl7p2o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GHn161YqjctgQMR+x7yu5+P0MBWok6WbjFIgETLBzCF2r3kfJH38xcvBAQbOzFc2z/O2dEdrn5SNFiHWu/F9ucsBCAulAI2pbidD9P0a6ggN2a8mLzlIoxgsBTmQah7hSluFGpaASHNrMHbO4BsXdnDlTqn/tespHT58GVtysUI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=6wind.com; spf=pass smtp.mailfrom=6wind.com; dkim=pass (2048-bit key) header.d=6wind.com header.i=@6wind.com header.b=gkcBv69a; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=6wind.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=6wind.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=6wind.com header.i=@6wind.com header.b="gkcBv69a" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-48e72b02bf6so3135055e9.3 for ; Mon, 18 May 2026 07:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; t=1779116385; x=1779721185; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:reply-to:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=vEWJGaCfr5moVa77HgCo0qOe0dfMae5hZJol18Jq5qo=; b=gkcBv69aqEtaBfZIhAqzwk6MhCvg9sxndlPNwSU0oSXzwKpw2m/eYtV47Rc8+boIjq 9TnUur6JbYwXGCbbLIhWbfGnWDTxGWv2pcnzgbp6qFGc9sXH080s5eWWgiCSP9KDqbNZ m7s2OcPExK77YyUpoHB42qs0YXl1wkFLg+smYHAv9Pjt7VNHy6VNsZuXPGwWcmeAAmXh 1VJipWGgVgmX9crrW0ZYz5P0zcSt05srdJw0+l1YgPGI125eKF7lw/irOqnf0H2f+zQx nVBG5+9389LQfbAVWrADJUZEGp3225MzUyVzDTjyDAVkDXrzOwRXgXHpx2JoFJcl8Zg6 /Weg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779116385; x=1779721185; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:reply-to:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vEWJGaCfr5moVa77HgCo0qOe0dfMae5hZJol18Jq5qo=; b=BL5RKEO+vnQNzlm9vPw6G2+1TR9J2DwUSMC/nHdgiFp7Eiw9wqbGGQBKA4MY45lzxj jovX9xUfSQEEWoTvtcuLxFVdMzECkE7VQzNKALF8kKQWoOWeROGreT07ibplnEvlYRlO NBDznIngfKqSYbyKd8Ffa1PD/uIcCzpJ8vD81SjNyKLni/KdLsMOewpxA+JV6catqNnJ R7Soz52n1ivqBQ/WPN7Sp9vWprEfGgQlTTxu3jHDt3cVITPfGDoA1EIAb9JdYFC/WExo 2tjJYR2HVeHdO98ZqHUA6QEKHeYOhyJxqNw1SZY9zP/FxU5nGfzTm6CqZzvAXqAFaCXu vJUQ== X-Forwarded-Encrypted: i=1; AFNElJ8Bexx3KWXari3vEUir/LrYcjLN36HIphTpzmtNQXa4Z/7Fn/LCQ4podQlb7YHjzD9lbe0NiWfbYJXSdM0=@vger.kernel.org X-Gm-Message-State: AOJu0YzJeFOghToxaW+oxZox6bL6mkdfsuei/lMY/qHGjyLkTffjJxd6 YxjF/vTUuEoAsct/LF9ooeoF0ZpfPlI2A0HrSfZRBGasKAIAAFVEqQoFc2WUS01w3Dc= X-Gm-Gg: Acq92OHDORCnmBX3c64uPEgoW1aey6QgsAjdZJkHeJ8Yk99vFk98yqrTY2wmR19cvL3 Trs6rK3ioEevqOGtoUBfzGA6F+2V6JVmhd+GuqhG8/Xw7p94ihcD7Pff9ftqf4B+3r85xadnqKC 0/H1cLtTYk4JPZmCglF6OeVjfn2Q71i5uRAIq0v5Wa8siz9ZyQ2hyhGJwk6WKcwusYt0c4eMqmJ EgujpV6xmywPzSC64b1Xv9hbxrT9VK4CxznTTF3nNcwqT1J63MmLGtcEZqX6zvwKO/2bducrvx0 wk2lG4RlFSwScvqwIWlsxuVGN9Xq7u3aITvXDJQeB5UP91vk2JCzMNIcJti51eVKC3pyLrIdaQ9 emb5vF5qrLJII8HMUK5JvAuarD6K4jMwb9YMshJiL3u3JI7K7S0SMVbpIgR6/Xl5e4bud+RglyX KR4JzxTTlvrOp4B8Ac0+402lBwAMoAW7XQ+HpJMd2/TzFJcfAkMpuyL+3HFextvCH7VkPs4EPc/ JWE X-Received: by 2002:a05:600c:4455:b0:489:1fa8:b895 with SMTP id 5b1f17b1804b1-48fe5fcb2dfmr120670715e9.2.1779116385579; Mon, 18 May 2026 07:59:45 -0700 (PDT) Received: from ?IPV6:2a01:e0a:b41:c160:6a1d:efff:fe52:1959? ([2a01:e0a:b41:c160:6a1d:efff:fe52:1959]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45da0a1a22csm36952961f8f.19.2026.05.18.07.59.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2026 07:59:45 -0700 (PDT) Message-ID: Date: Mon, 18 May 2026 16:59:44 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: nicolas.dichtel@6wind.com Subject: Re: [PATCH net 1/5] net: rtnetlink: fix link nsid reported when the link is local To: Ilya Maximets , Jiri Benc Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Donald Hunter , Shuah Khan , Adrian Moreno , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matteo Perin References: <20260515201937.2813983-1-i.maximets@ovn.org> <20260515201937.2813983-2-i.maximets@ovn.org> <20260518082138.37522db0@griffin> <8aa4e92d-0498-4335-b3b1-dabd7e507ed7@ovn.org> <5d4467d5-f081-4f7e-ac3c-9134ee8ddc6e@6wind.com> <30599c3d-66b5-4787-9ead-53ab716ba338@ovn.org> From: Nicolas Dichtel Content-Language: en-US Organization: 6WIND In-Reply-To: <30599c3d-66b5-4787-9ead-53ab716ba338@ovn.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Le 18/05/2026 à 15:55, Ilya Maximets a écrit : > On 5/18/26 2:46 PM, Nicolas Dichtel wrote: >> Le 18/05/2026 à 14:11, Ilya Maximets a écrit : >>> On 5/18/26 8:21 AM, Jiri Benc wrote: >>>> Hi Ilya, >>> >>> Hi, Jiri. Thanks for your thoughts on the matter! >>> >>>> >>>> IIRC this was added because Open vSwitch needed it. I'd expect most >>>> users that need to deal with cross-namespace detection to just switch >>>> to the given netns prior to issuing RTM_GETLINK; at least, that's what >>>> I'm doing in the tools I wrote. >>> >>> Yeah, that's also what other projects like FRR are doing. It's a bit >>> of a hustle for multi-threaded applications, as AFAIK, there is no way >>> to just move one thread into a different namespace, so if many threads >>> are doing something with the network and you suddenly need to check >>> something in a different namespace, you can't really do that without >>> pausing all other threads first. But that's a separate thing, unrelated >>> to the series. I'm just ranting. :) >> Hmm, not sure to understand. setns() is per thread (see man setns()). > > Hmm, I got my wires crossed here with something else, I suppose. > Though CAP_SYS_ADMIN requirement may be an even higher barrier. > >> >>> >>>> >>>> On Fri, 15 May 2026 22:19:20 +0200, Ilya Maximets wrote: >>>>> But this doesn't work for link nsid in cross-namespace RTM_GETLINK >>>>> requests. For some reason the code checks if the original device >>>>> and the link are in the same namespace and not if the querier's >>>>> namespace is the same as the link's. So the logic becomes: >>>>> >>>>> - if NSID is not reported, then the link is in the same namespace >>>>> as the queried device. >>>>> - if NSID is reported, then the link is not in the same namespace >>>>> with the queried device. >>>> >>>> I'm not sure I would call this a bug; the original idea was to use >>>> IFLA_IF_NETNSID to switch to the point of view of that netns but >>>> without actually switching to that netns. Hence, the netnsid is >>>> relative to the caller's netns but otherwise, you get the same reply as >>>> you would if you switched to that netns. If you think about it that >>>> way, the current reply is consistent. >>> >>> It makes some sense, but the fact that all-nsid notification and the >>> cross-namespace RTM_GETLINK provide different IDs makes it inconsistent >>> in my brain. We have: >>> >>> 1. nsenter(target) + getlink(local) = target-to-link nsid. >>> 2. getlink(target) = caller-to-target nsid + caller-to-link nsid. >>> 3. all-nsid-notiication = cmsg(caller-to-target nsid) + target-to-link nsid. >> >> all-nsid-notification appears before cross-getlink. >> The goal, for all-nsid-notification, was to be able to receive netlink messages >> of a subset of netns in one socket. So these messages are provided as-is, ie >> like if they were sent on a netlink socket opened in the corresponding netns. >> It's generic, there is no need to patch every subsystem. >> >> cross-get*() have been added later. The chosen behavior is friendlier at the >> cost of patching every subsystem that is supported. > > That's exactly my point. If we're creating a special patch for a subsystem, we > don't need to adhere to the exact structure of the original message, since the > data reported changes anyway. Sure, but only for this special path then (ie cross-get). My understanding is that you are interested by the all-nsid-notification path. > > IMO, not reporting nsid that is the same as the caller's nsid is more friendlier. > But that's, again, just a difference in opinion at this point, I'll not insist. The problem is changing the netlink API. As you said, a new flag would be needed for this. Regards, Nicolas