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

On Tue, Jun 02, 2026 at 02:46:22PM +0200, Andrew Lunn wrote:

On Tue, Jun 02, 2026 at 04:44:19PM +1000, David Gibson wrote:

quoted

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:

I've only been partially reading along...

Are we talking about RTM_NEWADDR?

Yes.

I've never worked on the code dealing with addresses. But in general,
if you want to add new functionality to a netlink message, you add a
new attribute to the message.

https://elixir.bootlin.com/linux/v7.0.10/source/include/uapi/linux/if_addr.h#L26

Ah, good point, that's another option, and avoids using scarce flags
bits.  It is a little bit odd, because generally the attributes are,
well, attributes, _of the new object_ being created (an address in
this case).  Here we're adjusting where / how it is created, not
anything about the address itself.

Stil, definitely a better option that allocating a new flags bit.
Versus NLM_F_APPEND, I'll reply to Ido Schimmel.

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