Re: [PATCH net v2] Revert "ipv6: preserve insertion order for same-scope addresses"

David Gibson <[email protected]>
Newsgroups dev.linux.lists.regressions,org.kernel.vger.netdev
Message-ID <ah_fejZd-lPr6AqM@zatzit>
On Wed, Jun 03, 2026 at 03:46:14PM +1000, Matthieu Baerts wrote:
> 
> 
> On 02/06/2026 00:01, Íñigo Huguet wrote:
> > On Mon, Jun 1, 2026 at 3:35 PM Stefano Brivio <[email protected]> wrote:
> >> I was thinking that if we implement a label like NLM_F_INSERT_LAST
> >> (David's proposal for the name), we could patch iproute2 to set it on
> >> 'ip address restore' at least, other than using it in pasta(1).
> 
> (...)
> 
> > What if we reapply the patch and add a NLM_F_INSERT_FIRST /
> > NLM_F_PREPEND option instead? This will break UAPI, which is bad, but
> > probably not too bad per the conversations in this and the other
> > thread. 
> 
> I guess it is safer not to break UAPI and not reapplying the patch,
> especially when there is no clear way to know which order is taken by
> the kernel.

I think Íñigo wasn't suggesting reapplying the patch as is, but a
modified version that only makes the behavioural change when userspace
sets a new attribute/flag/whatever.

> What about clearly stating that the default order is "random", except
> when an additional flag is set to sort them chronologically or the
> opposite?

We could, but since userspace relying on the existing behaviour is
already out there, I'm not sure what it buys us.  The insertion order
also isn't random - it's sorted by scope at least.  Theoretically
there could be other (existing) sorting criteria for other address
types (I haven't looked beyong IPv4 and IPv6).  The problem arises
because IPv4 and IPv6 have different behaviours when inserting
something where the order isn't defined - IPv4 inserts after existing
entries of the same scope, IPv6 puts it before existing entries of the
same scope - it's literally a < versus a <=.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmof320ACgkQzQJF27ox
2GdT4Q/+Pdyv4ttbRv9/hxDynh1JFBvIDwN77zvrMD9D9VZNFWTzFrSWI3fzkw1J
+narmMh4NtYObu26YzltRw2hq4pKMEkUYw14Tgx0okBBMX/kHzymNrSADC3GGJKG
MvHcTP03r/7pD+cnPF7d8DToYQDC3WfCsMKSg79OXmDOy9fdy3/8K21JtYv+m820
bPiQv77nbXBElhBnGENR6Oy4k7uyM7ga0TQFTxWWbzYeJSaVnHju33Fit+qdulnI
vZVX2Aj+g7MPdzHzF+wvA6+xp/vLKALA0Sut1uLzWiQAF5NRHKEoc9xO5QCl6N8l
r6XICQZN3/KwL5it+WLXgJkwVsahBjIwLE91hxWAtRI38gpSIPyDmmTqHRL9beTq
XfRb/fuuFVLT2TNs55G+iG0S7pstcoqzBhMIPUbh3K8kFVpRYx5B2Vhv/1DGNR0t
3emeU5M9kRXkH/VQpFshfeO7rNYQtlqtE+dssUQhpX3saNUczO4vfTnJlM9sYyT6
BoGzVGPlAImatDuJWwUGh1WiO4ceD1UfVQ/wJm0+dhadWabI5SWj/D5Cy2k/+rJv
EUOmUl+7a6j9fIrPkn7M+PFNnQKIi2r/fyvRqDmII4a3JMAGuGf8upziK3Xmf0a2
tjj7MgiG1AXcxBgogthYG9KXicHMhhiLtX+O2U0CnqCkWUXeUdk=
=0PGq
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.