From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=K8kIltCd; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 95A365A0262 for ; Mon, 09 Mar 2026 10:56:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773050171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lkJ2ym5K57aqeT5XtcBNCOGaDG6d2mN8fPN8s6QF/44=; b=K8kIltCdCgteoopxBkdPEwaR6SMpCLLY/dKX60OlNrXIvDTYN/7GuLkpVefgNZKFA8poiD fmtPzAOPGp7w6/SQnlaF5RPbrGeh176hjhw2EgsccXgEtMasMl4HLueXyKThp4gs1O2OEV GyDzT9TKG4WSz102QZTdPk9Q5eMl6vs= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-544-u5sDGXnSPCieSOtpv7W9fQ-1; Mon, 09 Mar 2026 05:56:09 -0400 X-MC-Unique: u5sDGXnSPCieSOtpv7W9fQ-1 X-Mimecast-MFC-AGG-ID: u5sDGXnSPCieSOtpv7W9fQ_1773050168 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-485390246c8so10619335e9.0 for ; Mon, 09 Mar 2026 02:56:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773050168; x=1773654968; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lkJ2ym5K57aqeT5XtcBNCOGaDG6d2mN8fPN8s6QF/44=; b=YOUVRk+Z2ShLfF4jEDcIyGOh2AMZLWT2hLkFnW8hNyxcrPXvn9tUJZluIv9xEjCTXo T+igmPF6V9QERZQ8dchPG6aMBd4un5muU7X4/RdjKxmIBNLdApyrAEOzHTPOMJgD6Td3 mtdqpG5iJrJwnY3FbGzAmLzgHMoQN52SJCDOi5QvXMgZNHdOigP2Ja5IpSz6zZSKZxjs Wn/yZVB7Af78CcDwuyBLJrK9qnHQZPnHcY4YYFBSPY5eWye0MK4T2xa1oYR6zeIMjBn1 QIpIHAFKFkW0rAO3ieo0983br5szbNTsatCsskeI34NojCGc6gY3aC+JBlWtEr7K93GF BrKg== X-Forwarded-Encrypted: i=1; AJvYcCUykLY2XRUinIM+ac+fM7WBIfmjWilTMwssMippnftEqO8TlxO4GYiCLxEe7TC9ehCLsolwlSQrtrU=@passt.top X-Gm-Message-State: AOJu0YwyHHdTHamvjS/m9011A42ZMSbsE3ULpVxr29mCQ7uhegKuhx8A K4kTdp4Oc4omiza7SCt/6RZvTGNFd4LlZwlbzhLZvR5csSG7DnQAjBnwYTkKbHCO0GJ5VAAqEvF bt73lJQr3VPPvcoScPvnw+dQDYMeQRAcbUYYmY+r88CHFDQx7ue7Yjg== X-Gm-Gg: ATEYQzyQvtF7tHtW2DIRFaaq2w62OaghAQ0pSJGariFr8r4/jVsMiuaJsMNBiFR56dd ogJnXVjZC6F7UWFS6DOearOg5uEzRnCzPl3c+lc4/2ncRyha66VQWKKuWI8d0ww1UAFYr5sK7JN Sku0+7qhpENNpxlBSj2ITLcOtR7tPiU45ZA0GMGzCCGlJSPGrwSbpO8Eewm+BsCYCMR4uBQI30i Pinsg0X122FdlvP0fdz2p/qEG2sJQ/85UO1oO6vcgbvGxP83csYz9hqTPff6Oqh4/srCebDtfDQ IZCJwEr7I1pqlLGxpQP6Ure7U07Kh3A6eb9i4B/+9HFnHWKVoWWZk9PQfT3QNa5NKZqhrmeF9pU j4XL9EYu4Q+JDtDDl8lzQolG9ZJTq4rGG X-Received: by 2002:a05:600c:3112:b0:485:3ff1:d5c5 with SMTP id 5b1f17b1804b1-4853ff1d6f2mr8357355e9.7.1773050168379; Mon, 09 Mar 2026 02:56:08 -0700 (PDT) X-Received: by 2002:a05:600c:3112:b0:485:3ff1:d5c5 with SMTP id 5b1f17b1804b1-4853ff1d6f2mr8356995e9.7.1773050167960; Mon, 09 Mar 2026 02:56:07 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dad977f8sm25035071f8f.9.2026.03.09.02.56.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 02:56:07 -0700 (PDT) From: Stefano Brivio To: Jon Maloy Subject: Re: [PATCH v3] netlink: Return prefix length for IPv6 addresses in nl_addr_get() Message-ID: <20260309105606.20a31e16@elisabeth> In-Reply-To: <20260307184157.1675234-1-jmaloy@redhat.com> References: <20260307184157.1675234-1-jmaloy@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Mon, 09 Mar 2026 10:56:07 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: RRX1tGqigTGOTFHiZK87_KzPATEgYw8SSsNprtY7-qo_1773050168 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: D52XRCN6P5ORWDYGT3L7TAKWI5RFFNAH X-Message-ID-Hash: D52XRCN6P5ORWDYGT3L7TAKWI5RFFNAH X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: dgibson@redhat.com, david@gibson.dropbear.id.au, passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: The patch looks good to me now, but I have two questions: On Sat, 7 Mar 2026 13:41:57 -0500 Jon Maloy wrote: > nl_addr_get() was not setting the prefix_len output parameter for > IPv6 addresses, only for IPv4. This meant callers always got 0 for > IPv6, forcing them to use a hardcoded default (64). > > Fix by assigning *prefix_len even in the IPv6 case. > > We also add another functional change. We now check for if an AF_INET > address is link local, in which case we have to skip it. The reason why the original code skipped IPv6 link-local addresses and not IPv4 link-local ones is that copying a IPv6 link-local address clearly makes no sense and breaks things. For IPv4 I wasn't quite sure, and it seemed to work just like other addresses, so I never took care of excluding them. I tend to think it's correct to exclude them, also for consistency with IPv6, but I'm not quite sure if we risk breaking something. I have some vague recollection of link-local addresses being used in some cloud (probably Google Computing Platform), at least for some Podman tests. I'll try to find some pointers to it. Did you already look into the matter, though? By the way, this makes things inconsistent with nl_addr_dup() (used by the vast majority of users), where IPv4 link-local addresses are copied just like all the other ones. > Although it > is conventional to set the scope of such addresses to RT_SCOPE_LINK, You mean that users manually do that? I think it's kind of rare actually. Does the kernel do that? Or configuration agents such as NetworkManager? I wonder a bit what you consider as "user" here. > this is not stated in any RFC, and we cannot trust it to have been set > correctly by the user, just as we cannot trust it to have been set > correctly for any other AF_INET address. We therefore add this check > explicitly on the address itself. -- Stefano