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:
>> On Tue, Jun 02, 2026 at 04:21:18PM +0300, Ido Schimmel wrote:
>>> On Tue, Jun 02, 2026 at 04:44:19PM +1000, David Gibson wrote:

[snip]

>>>> 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/[email protected]/
>>
>> 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