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=D04KjmSa; 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 293575A0262 for ; Mon, 09 Mar 2026 19:04:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773079484; 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=oe2sS400iY0/vS+MPYyfqXbhW1SCPpA1Hf5DfD4G4HM=; b=D04KjmSa9hpo+71DdlV4mqzH8GNFCebQkQN66ajtjFraqXlX6gOAf1wDfBAeZ/aIGFTzXH +4bbvgmnYazsTX9TU1wSb0y9S2bI3SwiZwj2VATvrrH79uNVqwuy+PspawjXCKAeNCqJMR SvzUPLpBBwDEIlpgEex4ThaBVMMTKfg= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-218-AN46tI9uMuCNDmQ6i2w-kA-1; Mon, 09 Mar 2026 14:04:42 -0400 X-MC-Unique: AN46tI9uMuCNDmQ6i2w-kA-1 X-Mimecast-MFC-AGG-ID: AN46tI9uMuCNDmQ6i2w-kA_1773079482 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-89a116bf0f8so432682616d6.0 for ; Mon, 09 Mar 2026 11:04:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773079482; x=1773684282; 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=oe2sS400iY0/vS+MPYyfqXbhW1SCPpA1Hf5DfD4G4HM=; b=NvGjxOkY+2brjSvS1ndmMSReYiWIWyOkuvvEbo0F49vpoRfJHlVs2u/wpMliDRIiJI vl1m7mzK5ZiG53Jrxesx+Ou311XMTX0KvMwVmym5d+6O+Ho8+D1FdcrqqwW+kkr2ET8K XflqrUUnfXk7fYdjKXXGFQXP/wd85YCtSyrzns3JBLo/uKJ0xtC+T4YghMPDBS7ONM5/ 4Q7D/M2T5jqnF15iDrgqbhukRMkAloeNvbAhNyPvoy7tT0vljXQqlBxeFJo3dHLyeDMB o643Z+E/QYqLE+gaw9sQcz8eI7LGdRjuwvtRQTOc44EoKKtFl6noF882E1K4uddRi1AE vZow== X-Forwarded-Encrypted: i=1; AJvYcCUEfymGoCEtEW2EN5k1aY2/VdvXS/r1ElsjC6KtRM1s7qmF5kXJ++7fzOOndOLcIBZOncBta2AlYN0=@passt.top X-Gm-Message-State: AOJu0YyjSactsp7lKs6WauyG/KopP/xXL5OBIICFez1CyPZXQQAmQvZo lnvuWDpsnF4s1ufQ9tyTx2aLQO8bDc3uZZ7u0SUKv9DSRU763Di0KzEEg9aqhfBtiKxHM3tzILv lEq5tlOI0FqCdkH7z8MXga8+BtCEztiqBC2Er0ZX8pYjfOmbLcVt3nA== X-Gm-Gg: ATEYQzyugSlMqxut7R5VO+SkvyBsHYnmbfrXvkgnk81RADxrMuSsf4DunwdycfU7d2o tYGNybJnw7rZ6DeOre10Wnf+IwpUEpfCJFXZHF5L4KhzsHpha/8ml4oyCeiRojBLZZBq4laMopt 9qVhBPYJxEaxA97suYKgO/fp67uDNaeV6VQxQYj7HscVVSsoEM37wufnsmvZsdRvYiRhP8C7s9l scxFzD/ouArU1IsRQ3USEttw2PSXjtmRvHhCEnBRqxpEul0SnHGiiU7icNOfuwk9RNM04HppVgd 3Ie6vu3Ftv9TYRpkazsXhjprIannvSDXElFjZ23mDp3/HP9M78lCRJSmVZsTvlNWZGVkYwbTQ12 fnPUiEQ8vx6q88A5Sy5X4A235D617H6uTKesP8kreY+OfL6W7OwAYDBP+urZuFfzGzIcF533XJj O2d6Qu/UI+yDKAJg== X-Received: by 2002:a05:6214:2462:b0:899:e8b8:8744 with SMTP id 6a1803df08f44-89a30b08c14mr180478656d6.57.1773079481989; Mon, 09 Mar 2026 11:04:41 -0700 (PDT) X-Received: by 2002:a05:6214:2462:b0:899:e8b8:8744 with SMTP id 6a1803df08f44-89a30b08c14mr180478036d6.57.1773079481465; Mon, 09 Mar 2026 11:04:41 -0700 (PDT) Received: from [192.168.2.15] (lnsm1-montreal01-69-158-139-121.internet.virginmobile.ca. [69.158.139.121]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89a57a3fbc9sm2827566d6.16.2026.03.09.11.04.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 11:04:41 -0700 (PDT) Message-ID: <6d36304d-af80-4ee0-8729-ca551c32d711@redhat.com> Date: Mon, 9 Mar 2026 14:04:40 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] netlink: Return prefix length for IPv6 addresses in nl_addr_get() To: Stefano Brivio References: <20260307184157.1675234-1-jmaloy@redhat.com> <20260309105606.20a31e16@elisabeth> From: Jon Maloy In-Reply-To: <20260309105606.20a31e16@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: UUcHif7_kZeKc5Jt31gG9_HMzfw7YFv_PBCuyKeIpw0_1773079482 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 22WQKOPSXJXVNH36ASLPNSQ5Q4X4G7TT X-Message-ID-Hash: 22WQKOPSXJXVNH36ASLPNSQ5Q4X4G7TT X-MailFrom: jmaloy@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: On 2026-03-09 05:56, Stefano Brivio wrote: > 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? Honestly I though it was just an oversight. > > 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. It is normally set by NetworkManager, but I don't think that means we can trust it at 100%. Anyway, I will remove this change in an update, as we agreed upon this morning. /jon > >> 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. >