[PATCH net v2] ipv6: sr: fix user space compilation error with old glibc

[PATCH net v2] ipv6: sr: fix user space compilation error with old glibc

[David Lebrun]

When seg6.h is included in a user space program that also includes
netinet/in.h, it results in multiple definitions of structures such as
struct in6_addr. Recent glibc versions have a workaround that consists in
defining __USE_KERNEL_IPV6_DEFS to prevent duplicates. However, such a
program will fail to compile with older glibc versions.

This patch ensures that including seg6.h will work in any case.

v2: do not try to handle __USE_KERNEL_IPV6_DEFS case in seg6.h

Fixes: ea3ebc73b46fbdb049dafd47543bb22efaa09c8e ("uapi: fix linux/seg6.h and linux/seg6_iptunnel.h userspace compilation errors")
Reported-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
 include/uapi/linux/seg6.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/seg6.h b/include/uapi/linux/seg6.h
index 7278511..4055ff3 100644
--- a/include/uapi/linux/seg6.h
+++ b/include/uapi/linux/seg6.h
@@ -15,7 +15,12 @@
 #define _UAPI_LINUX_SEG6_H
 
 #include <linux/types.h>
+
+#ifdef __KERNEL__
 #include <linux/in6.h>		/* For struct in6_addr. */
+#else
+#include <netinet/in.h>
+#endif
 
 /*
  * SRH
-- 
2.10.2

Re: [PATCH net v2] ipv6: sr: fix user space compilation error with old glibc

[David Miller]

From: David Lebrun <david.lebrun@uclouvain.be>
Date: Mon, 15 May 2017 13:03:20 +0200

> When seg6.h is included in a user space program that also includes
> netinet/in.h, it results in multiple definitions of structures such as
> struct in6_addr. Recent glibc versions have a workaround that consists in
> defining __USE_KERNEL_IPV6_DEFS to prevent duplicates. However, such a
> program will fail to compile with older glibc versions.
> 
> This patch ensures that including seg6.h will work in any case.
> 
> v2: do not try to handle __USE_KERNEL_IPV6_DEFS case in seg6.h
> 
> Fixes: ea3ebc73b46fbdb049dafd47543bb22efaa09c8e ("uapi: fix linux/seg6.h and linux/seg6_iptunnel.h userspace compilation errors")
> Reported-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>

Please, no.

The reason we put together a method by which glibc and the kernel can
stay out of eachother's way in header files is exactly so that we
don't need ifdefs that conditionally do netinet/in.h vs. using the
kernel header.

There are more than a dozen other UAPI headers which make use of
linux/in6.h and none of them jump through hoops like what is being
proposed here, and that's on purpose.

So special casing this one one header is really not the way to go.

Re: [PATCH net v2] ipv6: sr: fix user space compilation error with old glibc

[David Lebrun]

[-- Attachment #1.1: Type: text/plain, Size: 753 bytes --]

On 05/15/2017 04:09 PM, David Miller wrote:
> Please, no.
> 
> The reason we put together a method by which glibc and the kernel can
> stay out of eachother's way in header files is exactly so that we
> don't need ifdefs that conditionally do netinet/in.h vs. using the
> kernel header.
> 
> There are more than a dozen other UAPI headers which make use of
> linux/in6.h and none of them jump through hoops like what is being
> proposed here, and that's on purpose.
> 
> So special casing this one one header is really not the way to go.

Mmmh it's true that special casing in kernel headers for a user space
issue is not the best way to go.. I'll find a way to solve this in user
space only.

Sorry about the lousy patch.

David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH net v2] ipv6: sr: fix user space compilation error with old glibc

[Daniel Borkmann]

On 05/15/2017 04:21 PM, David Lebrun wrote:
> On 05/15/2017 04:09 PM, David Miller wrote:
>> Please, no.
>>
>> The reason we put together a method by which glibc and the kernel can
>> stay out of eachother's way in header files is exactly so that we
>> don't need ifdefs that conditionally do netinet/in.h vs. using the
>> kernel header.
>>
>> There are more than a dozen other UAPI headers which make use of
>> linux/in6.h and none of them jump through hoops like what is being
>> proposed here, and that's on purpose.
>>
>> So special casing this one one header is really not the way to go.
>
> Mmmh it's true that special casing in kernel headers for a user space
> issue is not the best way to go.. I'll find a way to solve this in user
> space only.
>
> Sorry about the lousy patch.

Any new outcomes so far?

Thanks,
Daniel