Re: IPv6 address insertion order (was Re: [PATCH net v2] Revert "ipv6: preserve insertion order for same-scope addresses")

[Ido Schimmel <idosch@nvidia.com>]

On Wed, Jun 03, 2026 at 12:34:36PM +1000, David Gibson wrote:
> On Tue, Jun 02, 2026 at 04:21:18PM +0300, Ido Schimmel wrote:
> > On Tue, Jun 02, 2026 at 04:44:19PM +1000, David Gibson wrote:
> > > I get the impression there's a rough consensus that the best we can do
> > > now is revert this change (already done), and make a new patch which
> > > changes the insertion order to the "correct" one conditional on a new
> > > flag.
> > > 
> > > Stefano has enough other fires to fight, so I'm taking a look at
> > > implementing that.  Some initial thoughts, that I'm soliciting
> > > feedback on:
> > > 
> > > 1) I'm assuming the idea here is to add the new flag to nlmsg_flags in
> > >    nlmsghdr
> > > 
> > > ifa_flags in ifaddrmsg would be the other candidate, but it looks like
> > > it's encoding properties of the address itself, not about the action
> > > of inserting it.  Plus all its bits are allocated, anyway.
> > > 
> > > 2) Could we re-use NLM_F_APPEND?
> > > 
> > > The short description of this existing flag in linux/uapi/netlink.h is
> > > "Add to end of list" which sounds like the right thing.  Looking
> > > closer, however, it seems like what is' used for so far is things
> > > where the entity added with the NEW<whatever> operation is itself a
> > > list, and NLM_F_APPEND causes it to be added to rather than replaced.
> > > It's not used for addresses at present, AFAICT the list of addresses
> > > is a semantic level above the address entity itself.
> > > 
> > > So maybe re-using it for the thing I tentatively called
> > > NLM_F_INSERT_LAST would be confusing?
> > > 
> > > On the other hand, it's not used for addresses at the moment, so
> > > AFAICT there's nothing actually preventing us reusing it for this
> > > purpose. That would save a bit - we only have 2 general and 4 NEW
> > > specific bits left, by the looks of it.
> > 
> > This is not really viable. Even if the kernel is not using NLM_F_APPEND
> > for RTM_NEWADDR, but not rejecting its presence either, then we can
> > create a change in behavior for a user space that is currently setting
> > it (intentionally or not).
> >
> > Example:
> > 
> > https://lore.kernel.org/netdev/27c249d80c346a258cfbf32f1d131ad4fe64e77c.camel@debian.org/
> 
> Hmm.  So, in this example case we have a known, widely deployed
> userspace that was broken by the change.  Similarly with the
> original now-reverted "fix" for the ordering, we have a known, widely
> deployed userspace that was broken.

It was also reported over three years after the kernel change went in.
Point is that we have no way of knowing how user space is using these
flags. Suddenly giving them meaning when we simply ignored them before
is risky.

> That's a different case from a hypothetical userspace that incorrectly
> used NLM_F_APPEND on RTM_NEWADDR.  Moreover, to be broken it would
> need to incorrectly use NLM_F_APPEND on RTM_NEWADDR *and also* rely on
> the counterintuitive and inconsistent insertion order for IPv6
> addresses.  Absent a concrete example of something meeting both those
> conditions, I'm inclined to breaking that hypothetical case when the
> payoff is an easier route to get known cases working with the
> preferred insertion semantics.
> 
> Fwiw, I did look at the most likely candidates: iproute2,
> network-manager and libvirt, and I see no signs that they're misusing
> NLM_F_APPEND in this way.

See above. I don't like this approach. IMO, it's not worth making it
slightly a bit easier for some user space programs to adopt when the
risk is breaking other programs and repeating this ordeal.