selftests/bpf: fix compile errors with older glibc

The older glibc (for example, 2.23) doesn't handle __UAPI_DEF_* in libc-compat.h properly, and it bring below compile errors:
"
In file included from test_tcpnotify_kern.c:12:
/usr/include/netinet/in.h:101:5: error: expected identifier
IPPROTO_HOPOPTS = 0, /* IPv6 Hop-by-Hop options. */
^
/usr/include/linux/in6.h:131:26: note: expanded from macro 'IPPROTO_HOPOPTS'

                                ^

In file included from test_tcpnotify_kern.c:12:
/usr/include/netinet/in.h:103:5: error: expected identifier
IPPROTO_ROUTING = 43, /* IPv6 routing header. */
^
/usr/include/linux/in6.h:132:26: note: expanded from macro 'IPPROTO_ROUTING'

                                ^

In file included from test_tcpnotify_kern.c:12:
/usr/include/netinet/in.h:105:5: error: expected identifier
IPPROTO_FRAGMENT = 44, /* IPv6 fragmentation header. */
^
/usr/include/linux/in6.h:133:26: note: expanded from macro 'IPPROTO_FRAGMENT' "
The same compile errors are reported for test_tcpbpf_kern.c too.

This patch fixes the compile errors by moving <netinet/in.h> to before the <linux/*.h>.

---
 tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c    | 2 +-
 tools/testing/selftests/bpf/progs/test_tcpnotify_kern.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

index 74f73b3..c7c3240 100644
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <stddef.h>
 #include <string.h>
+#include <netinet/in.h>
 #include <linux/bpf.h>
 #include <linux/if_ether.h>
 #include <linux/if_packet.h>

@@ -9,7 +10,6 @@
 #include <linux/types.h>
 #include <linux/socket.h>
 #include <linux/tcp.h>
-#include <netinet/in.h>
 #include "bpf_helpers.h"
 #include "bpf_endian.h"
 #include "test_tcpbpf.h"

index edbca20..ec6db6e 100644
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <stddef.h>
 #include <string.h>
+#include <netinet/in.h>
 #include <linux/bpf.h>
 #include <linux/if_ether.h>
 #include <linux/if_packet.h>

@@ -9,7 +10,6 @@
 #include <linux/types.h>
 #include <linux/socket.h>
 #include <linux/tcp.h>
-#include <netinet/in.h>
 #include "bpf_helpers.h"
 #include "bpf_endian.h"
 #include "test_tcpnotify.h"

1.8.5.6.2.g3d8a54e.dirty

I have an even old glibc 2.17 and it still works. Not sure why it failed here. Could you explain more?

But I applied the change, it still works with 2.17 glibc and gcc 4.8.5. So change probably safe.

We will meet these errors with the combination of some versions of kernel headers and some versions of glibc headers.

After some research on the git history of glibc and kernel, I find the reason behind the scene is a little complex:
There are some same definitions between glibc's netinet/in.h and kernel's linux/in6.h, IPPROTO_HOPOPTS, etc.
These same definitions willn't bring trouble when we include both of them if kernel and glibc coordinates with each other well, but the reality is the coordination is poor and unsynchronous in history.

Kernel and glibc uses guard macros to detect whether need to export their definitions, linux/in6.h includes libc-compat.h which will check the guard macro, _NETINET_IN_H, and netinet/in.h includes bits/in.h which will check the guard macro, _UAPI_LINUX_IN6_H (glibc-2.19~821 6c82a2f8d7c8e21e39237225c819f182ae438db3 "Coordinate IPv6 definitions for Linux and glibc"),

the problem is in the installation process of kernel headers, the "_UAPI" in _UAPI_LINUX_IN6_H in linux/in6.h will be stripped due to commit 56c176c9cac9
("UAPI: strip the _UAPI prefix from header guards during header installation").

The good news is the glibc fix this the trouble by checking the guard macro, _LINUX_IN6_H, too. (glibc c9bd40daaee18cf1d9824e4a7ebaebe321e0a5a8 "Bug 20214: Fix linux/in6.h and netinet/in.h sync.").

My environment still have this trouble:
lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial

dpkg -l | grep libc-dev:

ii  libc-dev-bin              2.23-0ubuntu11           amd64        GNU C Library: Development binaries
ii  linux-libc-dev:amd64      4.4.0-145.171            amd64        Linux Kernel Headers for development.

I will send out the v2 which I will change some words in changelog.

Thanks for review.

We will meet these errors with the combination of some versions of kernel headers and some versions of glibc headers.

After some research on the git history of glibc and kernel, I find the reason behind the scene is a little complex:
There are some same definitions between glibc's netinet/in.h and kernel's linux/in6.h, IPPROTO_HOPOPTS, etc.
These same definitions willn't bring trouble when we include both of them if kernel and glibc coordinates with each other well, but the reality is the coordination is poor and unsynchronous in history.

Kernel and glibc uses guard macros to detect whether need to export their definitions, linux/in6.h includes libc-compat.h which will check the guard macro, _NETINET_IN_H, and netinet/in.h includes bits/in.h which will check the guard macro, _UAPI_LINUX_IN6_H (glibc-2.19~821 6c82a2f8d7c8e21e39237225c819f182ae438db3 "Coordinate IPv6 definitions for Linux and glibc"),

the problem is in the installation process of kernel headers, the "_UAPI" in _UAPI_LINUX_IN6_H in linux/in6.h will be stripped due to commit 56c176c9cac9
("UAPI: strip the _UAPI prefix from header guards during header installation").

The good news is the glibc fix this the trouble by checking the guard macro, _LINUX_IN6_H, too. (glibc c9bd40daaee18cf1d9824e4a7ebaebe321e0a5a8 "Bug 20214: Fix linux/in6.h and netinet/in.h sync.").

My environment still have this trouble:
lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial

dpkg -l | grep libc-dev:

ii  libc-dev-bin              2.23-0ubuntu11           amd64        GNU C Library: Development binaries
ii  linux-libc-dev:amd64      4.4.0-145.171            amd64        Linux Kernel Headers for development.

I will send out the v2 which I will change some words in changelog.

Thanks for review.

Thanks for explanation, my system contains this glibc fix (_LINUX_IN6_H is checked) so that is why I did not have the issue.