From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (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 380893FDC00 for ; Mon, 18 May 2026 15:41:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779118884; cv=none; b=N/s5GpJFpFe151BhHbZIM5jw4iIugf/vrN5Wfm1vPhANHtLUPzhkqIS5iuNCH1Q0fyTd4ezgScAR/taBeDdju7HOZYOFoWPQzrETMfB5auY58uJSi4b0nZZBtLeFSzdcTAbMvjj9QN9tc2tfo58Tnv8VM+RwxTjVrtq8rFDvByw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779118884; c=relaxed/simple; bh=tk5GTPAK/nlnsOY7+TwdKEKLbFUPr/NxBIWdKs81b/o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pBJ4c4T0tjwdnxqh7yiSD9e20Zz6NHwS6EkDUelvjoLiuYLPmmC5tahV3qzLD88YkWjBiA9SMAW3W7snToN//v4FaRX8BIyu36iutxslcN2RdRgzqc2s3VB8BtDVXk0gdVkbpb3gHUgKRuHHU/JTu9u11n94stvsimYxADRLHvY= 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=XIWxQNX7; arc=none smtp.client-ip=209.85.128.47 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="XIWxQNX7" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4889d0a9df0so2529575e9.3 for ; Mon, 18 May 2026 08:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; t=1779118880; x=1779723680; 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=94Zjn9XQ3WDyXLdVoVZUdv+2NPn/y4aj79+Tl33qL2Y=; b=XIWxQNX7m8TQdntyMGgQxBLS1mv3Q6HmKWuxc1yDJmr66Utt283l/LZHrDrTkcGjHX +WaRfN/iivzLR/5GjTWkSKsehnGxQwRybuzaqWwG0ZprvVx2IEiZP1bwY2cOzcf927Nz YyEm8ntvVba7ATjnEzgw6yWHhAtgbyofN1KJNtvBfzfNJ8wXPN5eLuNl/gkrBShHXVvg elEHntUwzeIHS1eKPS2svpqTfzN/Z1QW6vREXZGM2KWFbXOmN26D5j1zK4HgSwy93yT3 AMXcyr1hvlnrf+K5E8B2O1uWwTDapAES05+zz6ECQI7q8eefHPgO4pV1CKck2m9PEx05 Va9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779118880; x=1779723680; 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=94Zjn9XQ3WDyXLdVoVZUdv+2NPn/y4aj79+Tl33qL2Y=; b=pr8lBBakQswPRxNtqpT01ZnG/eLYEqEain5zKZlSiPfrL5Sm7CtzZjJIsbBLD0fFPm H3G/EnSpiBRBuI2e21sfCcrO44tJ8SD+q/qo5nK0ytn0974X5/h09HT4+TEZgeQle11X ng5NAHsTlfZxj3h4CaVayQQr+ahH03Iod+qeUYQA+LxJ3+u04D5GCjqr878rARpCfo+K sZVx3MvOyhkGSOlqc7PdFD/gO7uoWUuPiyER0g/VLQapUhCw6/mzgTkfR4kmR+LiN/C0 LBNI0fRYMEs/yiLX7SxuGyH3HUJ47YAFjZBfN0draK+QEkGhv9Fw7qjTMC3CZMwn0pZ5 3zFQ== X-Forwarded-Encrypted: i=1; AFNElJ8fPDKL/0R4dMDm38z9exjxwHLepIgg0yPGqMZiviexDPQhYKuZlIGphls1yks9vS7YuOQ+XnOoBnRXMHo=@vger.kernel.org X-Gm-Message-State: AOJu0Yxq5AGK3e8vq6HtuN0vqKezekuXetROq0kVtk/y1QW0K0TYfkOh HDNrtI2TthnlOyKqciQFulI5cKrHHuS34ttMBDX7MuCrQJnzWLgGemk0tPLEmCOTtpQ= X-Gm-Gg: Acq92OH8UvWnhWOLiEQyMM3E+USHQ9fkJXfRhBSLhAOEyWEpZGDhD6Ruf4ZnC65YTTB fLRRTEWK5NAsGFb893gw1rgg5CjsjuYr+W2FI3Fg7R0E40L1JD9/0BpgvjSJ7p6qo+MFD/7SQac TGuD1hhxyEbxZY5rauSaKint6HP53AlcltDdyGg4lT8+PTY89JM+0R6I84ChLClmMWzpHy1GRL0 sKyM8MIx2MmlNh0OhlVNbAiiHCFCOyRt2TpPFUIRK1/ChswXNxA7zESZU+q18OV2w4dPw6XZn8j b1BeUdH5QkNG0vchm3yZVkC/P9O1spxNY3/hdXZt4zKXiiZnfsBrcM2NpRlDmx1mDq+9INFto41 gbDETCqOYvs+srJNUFTCiC7v5PkAE7962uZv9drVAeOlqUZ0BHqw5Y96MuYVvrFZV6Xjs6sgme7 uVzDikpmlWgRM449L0nsoTgJ9jqe1Fqx/9kTFm8PUstYN8EMYKOclI1nwjQFDuZmuG2IzmpvvS0 pfD0B5/NUyKyxAuOiZfi0x3Lg== X-Received: by 2002:a05:600c:1d02:b0:48a:5302:8ed9 with SMTP id 5b1f17b1804b1-48fe5ea0842mr143830215e9.0.1779118880533; Mon, 18 May 2026 08:41:20 -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-45da15a6449sm38102785f8f.37.2026.05.18.08.41.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2026 08:41:20 -0700 (PDT) Message-ID: Date: Mon, 18 May 2026 17:41:19 +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 3/5] net: netlink: don't set nsid on local notifications To: Ilya Maximets , netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Donald Hunter , Shuah Khan , Adrian Moreno , Jiri Benc , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Matteo Perin References: <20260515201937.2813983-1-i.maximets@ovn.org> <20260515201937.2813983-4-i.maximets@ovn.org> <40603dce-f801-42ad-96ec-c8c0a57e5aae@6wind.com> <5344852f-e920-4232-9b54-5b22f6c8a1d3@ovn.org> <5d19e543-ac3b-4d32-a464-377d03cde500@6wind.com> From: Nicolas Dichtel Content-Language: en-US Organization: 6WIND In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Le 18/05/2026 à 16:06, Ilya Maximets a écrit : > On 5/18/26 2:56 PM, Nicolas Dichtel wrote: >> Le 18/05/2026 à 14:46, Ilya Maximets a écrit : >> >> [snip] >> >>> True and also not really. The main problem is that ID can be allocated >>> at any point in time, so the application needs to listen for NEW messages >>> on the same socket that it is listening for the events that are interesting >>> to it (to avoid races), if it doesn't want to make a separate GET request >>> per notification or track all the IDs that were previously checked. It's a >>> non-trivial amount of code depending on the application structure. >> iproute2 handles it ;-) > > I don't think it does. If I run this in one terminal: > > ip netns add test-ns > ip netns exec test-ns ip monitor link all-nsid > > And then in the other terminal: > > ip -n test-ns link add dummy1 type dummy > ip netns exec test-ns ip netns set test-ns 100 > ip -n test-ns link add dummy2 type dummy > ip netns del test-ns > > I see the following events: > > [nsid current]2: dummy1: ... > [nsid 100]3: dummy2: ... > > Which is confusing to the user (myself) and shows that iproute2 doesn't > know or doesn't care (which may be fine for this particular command) that > 100 is the ID of the current namespace. Right, it doesn't update its cache. I thought I fixed this :D [snip] >> I need to make some tests with your series. > > Note: sashiko points out that it may be possible to have stale values reported, so > re-setting the nsid_is_set flag unconditionally before the check may be required, > e.g.: > > + NETLINK_CB(p->skb2).nsid_is_set = false; > if (!net_eq(sock_net(sk), p->net)) { > NETLINK_CB(p->skb2).nsid = peernet2id(sock_net(sk), p->net); > if (NETLINK_CB(p->skb2).nsid != NETNSA_NSID_NOT_ASSIGNED) > NETLINK_CB(p->skb2).nsid_is_set = true; > } > > I'll include that in v2. I will wait for the v2 to test the series. Regards, Nicolas