Date:   Tue, 19 Mar 2019 17:51:09 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     linux-api@...r.kernel.org
Cc:     linux-arch@...r.kernel.org, netdev@...r.kernel.org,
        Laura Abbott <labbott@...hat.com>,
        Arnd Bergmann <arnd@...db.de>,
        Florian Weimer <fw@...eb.enyo.de>,
        Paul Burton <pburton@...ecomp.com>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        linux-kernel@...r.kernel.org
Subject: [PATCH] uapi: avoid namespace conflict in linux/posix_types.h

Florian Weimer points out an issue with including linux/posix_types.h
from arbitrary other headers: if an application has defined a macro
named 'fds_bits', it may stop compiling after a change in the kernel
headers. Since fds_bits is a non-reserved identifier in C, that is
considered a bug in the kernel headers.

The structure definition does not really seem to be helpful here,
as the kernel no longer provides macros to manipulate it.

The only user of the structure that we could find was in libsanitize.
This usage is actually broken, as discussed in the email thread,
but this means we cannot just remove the definition from the exported
headers, but we can use the __kernel_* namespace for it, to avoid
the namespace conflict. The kernel itself just uses bit operations
on the typedef without accessing the field by name.
This change should also help with the many other kernel headers that
include linux/posix_types.h directly or through linux/types.h.

Similarly, the definition of __kernel_fsid_t uses a structure with
field identifier 'val' that may have the same problem. Again, user
space should not rely on the specific field name but instead treat
an fsid_t as an opaque identifier. I'm using an #ifdef __KERNEL__
guard here to save us from having to change all kernel code accessing
the field.
Glibc has changed this from 'val' to '__val' back in 1996/97 when
they moved away from using the kernel types directly, it it
is likely that nothing uses __kernel_fsid_t any more. MIPS still
has another copy of __kernel_fsid_t, but that is in the process
of being removed as well.

Link: https://lore.kernel.org/lkml/87a7hvded7.fsf@mid.deneb.enyo.de/
Link: https://lore.kernel.org/lkml/20190314173900.25454-1-paul.burton@mips.com/
Cc: Florian Weimer <fw@...eb.enyo.de>
Cc: Paul Burton <pburton@...ecomp.com>
Fixes: a623a7a1a567 ("y2038: fix socket.h header inclusion")
Signed-off-by: Arnd Bergmann <arnd@...db.de>
---
There was another bug report for the same change just now, so
I wouldn't apply this patch yet before we have fully understood
the other issue. Sending this for review now since the two
problems are most likely independent.
---
 include/uapi/asm-generic/posix_types.h | 4 ++++
 include/uapi/linux/posix_types.h       | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
index f0733a26ebfc..2a8c68ac88ca 100644
--- a/include/uapi/asm-generic/posix_types.h
+++ b/include/uapi/asm-generic/posix_types.h
@@ -77,7 +77,11 @@ typedef __kernel_long_t	__kernel_ptrdiff_t;
 
 #ifndef __kernel_fsid_t
 typedef struct {
+#ifdef __KERNEL__
 	int	val[2];
+#else
+	int	__kernel_val[2];
+#endif
 } __kernel_fsid_t;
 #endif
 
diff --git a/include/uapi/linux/posix_types.h b/include/uapi/linux/posix_types.h
index 9a7a740b35a2..a5a5cfc38bbf 100644
--- a/include/uapi/linux/posix_types.h
+++ b/include/uapi/linux/posix_types.h
@@ -23,7 +23,7 @@
 #define __FD_SETSIZE	1024
 
 typedef struct {
-	unsigned long fds_bits[__FD_SETSIZE / (8 * sizeof(long))];
+	unsigned long __kernel_fds_bits[__FD_SETSIZE / (8 * sizeof(long))];
 } __kernel_fd_set;
 
 /* Type of a signal handler.  */
-- 
2.20.0

Powered by blists - more mailing lists