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

On Wed, Jun 03, 2026 at 03:46:14PM +1000, Matthieu Baerts wrote:

On 02/06/2026 00:01, Íñigo Huguet wrote:

quoted

On Mon, Jun 1, 2026 at 3:35 PM Stefano Brivio [off-list ref] wrote:

quoted

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

(...)

quoted

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