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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]