public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: Jon Maloy <jmaloy@redhat.com>
Cc: dgibson@redhat.com, david@gibson.dropbear.id.au, passt-dev@passt.top
Subject: Re: [PATCH v3] netlink: Return prefix length for IPv6 addresses in nl_addr_get()
Date: Mon, 09 Mar 2026 10:56:07 +0100 (CET)	[thread overview]
Message-ID: <20260309105606.20a31e16@elisabeth> (raw)
In-Reply-To: <20260307184157.1675234-1-jmaloy@redhat.com>

The patch looks good to me now, but I have two questions:

On Sat,  7 Mar 2026 13:41:57 -0500
Jon Maloy <jmaloy@redhat.com> 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


      parent reply	other threads:[~2026-03-09  9:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-07 18:41 Jon Maloy
2026-03-09  9:47 ` David Gibson
2026-03-09  9:56 ` Stefano Brivio [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260309105606.20a31e16@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgibson@redhat.com \
    --cc=jmaloy@redhat.com \
    --cc=passt-dev@passt.top \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).