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-----