Details

I can't find any use of it in our tree, and the only Linux documentation I found (https://www.man7.org/linux/man-pages/man7/rtnetlink.7.html) says "ifi_change is reserved for future use and should be always set to 0xFFFFFFFF."

What am I missing?

In D51871#1185494, @kp wrote:

So that seems correct if ifi_change lists the changed flags we should look at.

I can't find any use of it in our tree, and the only Linux documentation I found (https://www.man7.org/linux/man-pages/man7/rtnetlink.7.html) says "ifi_change is reserved for future use and should be always set to 0xFFFFFFFF."

What am I missing?

Linux is actually doing something based on ifi_change currently (relevant code in net/core/rtnetlink.c, rtnl_dev_combine_flags).

It uses the previous flags for bits where ifi_change are unset to change device flags, so basically this is equivalent to what our code does.
The exception is when ifi_change is 0, then it assumes it is 0xFFFFFFFF, which differs in behaviour to our code (we should do (lattrs->ifi_change & IFF_UP) != 0 || lattrs->ifi_change == 0 to emulate this).

So I guess we should decide whether to stick to the documentation then or keep things in line with Linux. Thoughts?

In D51871#1185506, @obiwac wrote:

Linux is actually doing something based on ifi_change currently (relevant code in net/core/rtnetlink.c, rtnl_dev_combine_flags).

Ah yes, "Documentation does not match reality", that's what I was missing. I did not check Linux code, I only looked at our tree.

It uses the previous flags for bits where ifi_change are unset to change device flags, so basically this is equivalent to what our code does.
The exception is when ifi_change is 0, then it assumes it is 0xFFFFFFFF, which differs in behaviour to our code (we should do (lattrs->ifi_change & IFF_UP) != 0 || lattrs->ifi_change == 0 to emulate this).

So I guess we should decide whether to stick to the documentation then or keep things in line with Linux. Thoughts?

I'd be inclined to pick up Linux's bug compatibility as well. Presumably there's code out there that makes this incorrect assumption about ifi_change, and we may as well go all out on being compatible. Especially if it's easy to do. That can be done separately if you prefer (or not at all, if either of you have strong views here).

In D51871#1185539, @kp wrote:

I'd be inclined to pick up Linux's bug compatibility as well. Presumably there's code out there that makes this incorrect assumption about ifi_change, and we may as well go all out on being compatible. Especially if it's easy to do. That can be done separately if you prefer (or not at all, if either of you have strong views here).

I too think we should have this bug compatibility

In D51871#1185539, @kp wrote:

I'd be inclined to pick up Linux's bug compatibility as well. Presumably there's code out there that makes this incorrect assumption about ifi_change, and we may as well go all out on being compatible. Especially if it's easy to do. That can be done separately if you prefer (or not at all, if either of you have strong views here).