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

Le 03/06/2026 à 09:47, Ido Schimmel a écrit :

On Wed, Jun 03, 2026 at 12:34:36PM +1000, David Gibson wrote:

quoted

On Tue, Jun 02, 2026 at 04:21:18PM +0300, Ido Schimmel wrote:

quoted

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

[snip]

quoted

quoted

quoted

2) Could we re-use NLM_F_APPEND?

The short description of this existing flag in linux/uapi/netlink.h is
"Add to end of list" which sounds like the right thing.  Looking
closer, however, it seems like what is' used for so far is things
where the entity added with the NEW<whatever> operation is itself a
list, and NLM_F_APPEND causes it to be added to rather than replaced.
It's not used for addresses at present, AFAICT the list of addresses
is a semantic level above the address entity itself.

So maybe re-using it for the thing I tentatively called
NLM_F_INSERT_LAST would be confusing?

On the other hand, it's not used for addresses at the moment, so
AFAICT there's nothing actually preventing us reusing it for this
purpose. That would save a bit - we only have 2 general and 4 NEW
specific bits left, by the looks of it.

This is not really viable. Even if the kernel is not using NLM_F_APPEND
for RTM_NEWADDR, but not rejecting its presence either, then we can
create a change in behavior for a user space that is currently setting
it (intentionally or not).

Example:

https://lore.kernel.org/netdev/27c249d80c346a258cfbf32f1d131ad4fe64e77c.camel@debian.org/ (local)

Hmm.  So, in this example case we have a known, widely deployed
userspace that was broken by the change.  Similarly with the
original now-reverted "fix" for the ordering, we have a known, widely
deployed userspace that was broken.

It was also reported over three years after the kernel change went in.
Point is that we have no way of knowing how user space is using these
flags. Suddenly giving them meaning when we simply ignored them before
is risky.

+1