Sync linux headers to 4.19.66

[michaelforney]

This fixes the build with musl libc.

Additionally, several changes were made to account for changes to the
headers:

• ip_mp_alg.h was removed, since it was removed in linux commit torvalds/linux@e06e7c61
  (v2.6.23), and the last use of those constants was removed in libnl
  commit 535e831.
• Uses of TCF_META_ID_SK_ROUTE_CAPS were updated to
  __TCF_META_ID_SK_ROUTE_CAPS, since it was renamed in linux commit
  torvalds/linux@e20e6940 (v3.1).
• Uses of IF_CARRIER_DOWN and IF_CARRIER_UP were replaced with their
  values, 0 and 1, since they are not in linux/if.h (they appear to be
  libnl-specific, added in libnl commit 3540e44).

[michaelforney]

Hmm... it looks like uint16_t, used for parameter ext in idiagnl_send_simple is no longer big enough to store _INET_DIAG_ALL. Not sure what to do about this.

[thom311]

I merged the pull-request. Thank you!!

Hmm... it looks like uint16_t, used for parameter ext in idiagnl_send_simple is no longer big enough to store _INET_DIAG_ALL. Not sure what to do about this.

Right. Internally it even only considers 8 bits, so 0xFF00 flags are ignored as well.

How about 1940695 ? For now I just added a comment about that. If anybody requires this to work, patch welcome.

[michaelforney]

Thanks, your fix looks fine.

When looking into this issue, I found that to support these higher extensions, the kernel actually overloads the lower extensions, or just always returns them under certain conditions. For example, INET_DIAG_DCTCPINFO, INET_DIAG_BBRINFO, and INET_DIAG_VEGASINFO are all returned when you request INET_DIAG_VEGASINFO, and INET_DIAG_MARK is returned if you have CAP_NET_ADMIN (for example, https://github.com/torvalds/linux/blob/a55aa89aab90fae7c815b0551b07be37db359d76/net/ipv4/tcp_dctcp.c#L187-L191).

So, sending _INET_DIAG_ALL truncated to 16 bits probably does the right thing and returns the higher extensions as well. The only remaining issue would be if idiagnl_send_simple were used directly. In that case, the caller would have to be aware of this limitation and make sure ext specifies the corresponding lower value. If a idiagnl_send_simple2 were to be added with a uint32_t parameter, perhaps it could map the higher bits onto the lower ones before sending the request.

(Disclaimer: I have no idea what any of this idiag stuff does, these are just the results of my investigation of the build failure)