Various UAPI headers reference 'struct sockaddr'. Currently the
definition of this struct is pulled in from the libc header
sys/socket.h. This is problematic as it introduces a dependency
on a full userspace toolchain.

Instead expose a custom but compatible definition of 'struct sockaddr'
in the UAPI headers. It is guarded by the libc compatibility
infrastructure to avoid potential conflicts.

The compatibility symbol won't be supported by glibc right away,
but right now __UAPI_DEF_IF_IFNAMSIZ is not supported either,
so including the libc headers before the UAPI headers is broken anyways.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/linux/socket.h           | 10 ----------
 include/uapi/linux/if.h          |  4 ----
 include/uapi/linux/libc-compat.h | 12 ++++++++++++
 include/uapi/linux/socket.h      | 14 ++++++++++++++
 4 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index ec715ad4bf25..8363d4e0a044 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -28,16 +28,6 @@ extern void socket_seq_show(struct seq_file *seq);
 
 typedef __kernel_sa_family_t	sa_family_t;
 
-/*
- *	1003.1g requires sa_family_t and that sa_data is char.
- */
-
-/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */
-struct sockaddr {
-	sa_family_t	sa_family;	/* address family, AF_xxx	*/
-	char		sa_data[14];	/* 14 bytes of protocol address	*/
-};
-
 /**
  * struct sockaddr_unsized - Unspecified size sockaddr for callbacks
  * @sa_family: Address family (AF_UNIX, AF_INET, AF_INET6, etc.)
diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
index 797ba2c1562a..a4bc54196a07 100644
--- a/include/uapi/linux/if.h
+++ b/include/uapi/linux/if.h
@@ -25,10 +25,6 @@
 #include <linux/socket.h>		/* for "struct sockaddr" et al	*/
 #include <linux/compiler.h>		/* for "__user" et al           */
 
-#ifndef __KERNEL__
-#include <sys/socket.h>			/* for struct sockaddr.		*/
-#endif
-
 #if __UAPI_DEF_IF_IFNAMSIZ
 #define	IFNAMSIZ	16
 #endif /* __UAPI_DEF_IF_IFNAMSIZ */
diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
index 0eca95ccb41e..13a06ce4e825 100644
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -140,6 +140,13 @@
 
 #endif /* _NETINET_IN_H */
 
+/* Definitions for socket.h */
+#if defined(_SYS_SOCKET_H)
+#define __UAPI_DEF_SOCKADDR		0
+#else
+#define __UAPI_DEF_SOCKADDR		1
+#endif
+
 /* Definitions for xattr.h */
 #if defined(_SYS_XATTR_H)
 #define __UAPI_DEF_XATTR		0
@@ -221,6 +228,11 @@
 #define __UAPI_DEF_IP6_MTUINFO		1
 #endif
 
+/* Definitions for socket.h */
+#ifndef __UAPI_DEF_SOCKADDR
+#define __UAPI_DEF_SOCKADDR		1
+#endif
+
 /* Definitions for xattr.h */
 #ifndef __UAPI_DEF_XATTR
 #define __UAPI_DEF_XATTR		1
diff --git a/include/uapi/linux/socket.h b/include/uapi/linux/socket.h
index d3fcd3b5ec53..35d7d5f4b1a8 100644
--- a/include/uapi/linux/socket.h
+++ b/include/uapi/linux/socket.h
@@ -2,6 +2,8 @@
 #ifndef _UAPI_LINUX_SOCKET_H
 #define _UAPI_LINUX_SOCKET_H
 
+#include <linux/libc-compat.h>          /* for compatibility with glibc */
+
 /*
  * Desired design of maximum size and alignment (see RFC2553)
  */
@@ -26,6 +28,18 @@ struct __kernel_sockaddr_storage {
 	};
 };
 
+/*
+ *	1003.1g requires sa_family_t and that sa_data is char.
+ */
+
+/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */
+#if __UAPI_DEF_SOCKADDR
+struct sockaddr {
+	__kernel_sa_family_t	sa_family;	/* address family, AF_xxx	*/
+	char			sa_data[14];	/* 14 bytes of protocol address	*/
+};
+#endif /* __UAPI_DEF_SOCKADDR */
+
 #define SOCK_SNDBUF_LOCK	1
 #define SOCK_RCVBUF_LOCK	2
 

---
base-commit: dbf8fe85a16a33d6b6bd01f2bc606fc017771465
change-id: 20251222-uapi-sockaddr-cf10e7624729

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

On Mon, 05 Jan 2026 09:25:55 +0100 Thomas Weißschuh wrote:
> Various UAPI headers reference 'struct sockaddr'. Currently the
> definition of this struct is pulled in from the libc header
> sys/socket.h. This is problematic as it introduces a dependency
> on a full userspace toolchain.
> 
> Instead expose a custom but compatible definition of 'struct sockaddr'
> in the UAPI headers. It is guarded by the libc compatibility
> infrastructure to avoid potential conflicts.
> 
> The compatibility symbol won't be supported by glibc right away,
> but right now __UAPI_DEF_IF_IFNAMSIZ is not supported either,
> so including the libc headers before the UAPI headers is broken anyways.

I did not look too closely but this seems to break build of selftests
in netdev and BPF CI (netdev on AWS Linux, not sure what base BPF uses)

Hi Jakub,

On Mon, Jan 05, 2026 at 09:57:13AM -0800, Jakub Kicinski wrote:
> On Mon, 05 Jan 2026 09:25:55 +0100 Thomas Weißschuh wrote:
> > Various UAPI headers reference 'struct sockaddr'. Currently the
> > definition of this struct is pulled in from the libc header
> > sys/socket.h. This is problematic as it introduces a dependency
> > on a full userspace toolchain.
> > 
> > Instead expose a custom but compatible definition of 'struct sockaddr'
> > in the UAPI headers. It is guarded by the libc compatibility
> > infrastructure to avoid potential conflicts.
> > 
> > The compatibility symbol won't be supported by glibc right away,
> > but right now __UAPI_DEF_IF_IFNAMSIZ is not supported either,
> > so including the libc headers before the UAPI headers is broken anyways.
> 
> I did not look too closely but this seems to break build of selftests
> in netdev and BPF CI (netdev on AWS Linux, not sure what base BPF uses)

Thanks for the report.

I found the reported CI failures in BPF CI and will work on those.

As for the failure in netdev CI however I am not so sure.
Looking at net-next-2026-01-05--12-00, the only failures triggered by my
change are also the ones from the bpf-ci. Are these the ones you meant,
or am I missing some others?


Thomas

On Tue, 6 Jan 2026 11:32:52 +0100 Thomas Weißschuh wrote:
> As for the failure in netdev CI however I am not so sure.
> Looking at net-next-2026-01-05--12-00, the only failures triggered by my
> change are also the ones from the bpf-ci. Are these the ones you meant,
> or am I missing some others?

Multiple things broke at once so slightly hard to fish the relevant
stuff out from here:

https://netdev.bots.linux.dev/contest.html?branch=net-next-2026-01-05--15-00&pass=0&pw-n=0

Here's one:

make[1]: Entering directory '/home/virtme/testing/wt-3/tools/testing/selftests/net'
  CC       busy_poller
In file included from [01m[K/usr/include/sys/socket.h:33[m[K,
                 from [01m[K/usr/include/netinet/in.h:23[m[K,
                 from [01m[K/usr/include/arpa/inet.h:22[m[K,
                 from [01m[Kbusy_poller.c:14[m[K:
[01m[K/usr/include/bits/socket.h:182:8:[m[K [01;31m[Kerror: [m[Kredefinition of '[01m[Kstruct sockaddr[m[K'
  182 | struct [01;31m[Ksockaddr[m[K
      |        [01;31m[K^~~~~~~~[m[K
In file included from [01m[K/home/virtme/testing/wt-3/usr/include/linux/netlink.h:6[m[K,
                 from [01m[K/home/virtme/testing/wt-3/usr/include/linux/genetlink.h:6[m[K,
                 from [01m[K/home/virtme/testing/wt-3/tools/testing/selftests/../../../tools/net/ynl/lib/ynl.h:7[m[K,
                 from [01m[Kbusy_poller.c:12[m[K:
[01m[K/home/virtme/testing/wt-3/usr/include/linux/socket.h:37:8:[m[K [01;36m[Knote: [m[Koriginally defined here
   37 | struct [01;36m[Ksockaddr[m[K {
      |        [01;36m[K^~~~~~~~[m[K
make[1]: *** [../lib.mk:225: /home/virtme/testing/wt-3/tools/testing/selftests/net/busy_poller] Error 1

https://netdev-3.bots.linux.dev/vmksft-net-dbg/results/460421/7-xfrm-policy-sh/stdout

On Wed, Jan 7, 2026, at 00:13, Jakub Kicinski wrote:
> On Tue, 6 Jan 2026 11:32:52 +0100 Thomas Weißschuh wrote:
>> As for the failure in netdev CI however I am not so sure.
>> Looking at net-next-2026-01-05--12-00, the only failures triggered by my
>> change are also the ones from the bpf-ci. Are these the ones you meant,
>> or am I missing some others?
>
> Multiple things broke at once so slightly hard to fish the relevant
> stuff out from here:
>
> https://netdev.bots.linux.dev/contest.html?branch=net-next-2026-01-05--15-00&pass=0&pw-n=0
>
> Here's one:
>
> make[1]: Entering directory 
> '/home/virtme/testing/wt-3/tools/testing/selftests/net'
>   CC       busy_poller
> In file included from [01m[K/usr/include/sys/socket.h:33[m[K,
>                  from [01m[K/usr/include/netinet/in.h:23[m[K,
>                  from [01m[K/usr/include/arpa/inet.h:22[m[K,
>                  from [01m[Kbusy_poller.c:14[m[K:
> [01m[K/usr/include/bits/socket.h:182:8:[m[K [01;31m[Kerror: 
> [m[Kredefinition of '[01m[Kstruct sockaddr[m[K'

>                  from [01m[Kbusy_poller.c:12[m[K:
> [01m[K/home/virtme/testing/wt-3/usr/include/linux/socket.h:37:8:[m[K 
> [01;36m[Knote: [m[Koriginally defined here

Maybe we can change all the instances of 'struct sockaddr' in
include/uapi/ to reference a new 'struct __kernel_sockaddr',
and then redirect that one if the libc header got included
first?

struct __kernel_sockaddr {
       __kernel_sa_family_t    sa_family;      /* address family, AF_xxx       */
       char sa_data_min[14];           /* Minimum 14 bytes of protocol address */
};
#ifdef _SYS_SOCKET_H
#define __kernel_sockaddr sockaddr
#endif

This will still fail when a user application includes linux/if.h
before sys/socket.h and then expects the structures in linux/if.h
to contain the libc version of sockaddr, but hopefully that is
much rarer. A survey of codesearch.debian.net shows almost all
users of linux/if.h first including sys/socket.h, and most of
them not caring about struct sockaddr either.

      Arnd

* Arnd Bergmann:

> On Wed, Jan 7, 2026, at 00:13, Jakub Kicinski wrote:
>> On Tue, 6 Jan 2026 11:32:52 +0100 Thomas Weißschuh wrote:
>>> As for the failure in netdev CI however I am not so sure.
>>> Looking at net-next-2026-01-05--12-00, the only failures triggered by my
>>> change are also the ones from the bpf-ci. Are these the ones you meant,
>>> or am I missing some others?
>>
>> Multiple things broke at once so slightly hard to fish the relevant
>> stuff out from here:
>>
>> https://netdev.bots.linux.dev/contest.html?branch=net-next-2026-01-05--15-00&pass=0&pw-n=0
>>
>> Here's one:
>>
>> make[1]: Entering directory 
>> '/home/virtme/testing/wt-3/tools/testing/selftests/net'
>>   CC       busy_poller
>> In file included from [01m[K/usr/include/sys/socket.h:33[m[K,
>>                  from [01m[K/usr/include/netinet/in.h:23[m[K,
>>                  from [01m[K/usr/include/arpa/inet.h:22[m[K,
>>                  from [01m[Kbusy_poller.c:14[m[K:
>> [01m[K/usr/include/bits/socket.h:182:8:[m[K [01;31m[Kerror: 
>> [m[Kredefinition of '[01m[Kstruct sockaddr[m[K'
>
>>                  from [01m[Kbusy_poller.c:12[m[K:
>> [01m[K/home/virtme/testing/wt-3/usr/include/linux/socket.h:37:8:[m[K 
>> [01;36m[Knote: [m[Koriginally defined here
>
> Maybe we can change all the instances of 'struct sockaddr' in
> include/uapi/ to reference a new 'struct __kernel_sockaddr',
> and then redirect that one if the libc header got included
> first?
>
> struct __kernel_sockaddr {
>        __kernel_sa_family_t    sa_family;      /* address family, AF_xxx       */
>        char sa_data_min[14];           /* Minimum 14 bytes of protocol address */
> };
> #ifdef _SYS_SOCKET_H
> #define __kernel_sockaddr sockaddr
> #endif
>
> This will still fail when a user application includes linux/if.h
> before sys/socket.h and then expects the structures in linux/if.h
> to contain the libc version of sockaddr, but hopefully that is
> much rarer. A survey of codesearch.debian.net shows almost all
> users of linux/if.h first including sys/socket.h, and most of
> them not caring about struct sockaddr either.

If you call the data member sa_data just like glibc, it will only fail
in C++, not C.  GCC considers the two definitions sufficiently
equivalent (even though glibc adds a may_alias attribute to meet POSIX
requirements), and duplicate definitions are permitted in C.

C++ with modules will probably support duplicate definitions, too, but I
haven't checked if it's possible to get this work with GCC 16.

Thanks,
Florian

On Mon, Jan 12, 2026 at 12:42:17PM +0100, Florian Weimer wrote:
> * Arnd Bergmann:
> 
> > On Wed, Jan 7, 2026, at 00:13, Jakub Kicinski wrote:
> >> On Tue, 6 Jan 2026 11:32:52 +0100 Thomas Weißschuh wrote:
> >>> As for the failure in netdev CI however I am not so sure.
> >>> Looking at net-next-2026-01-05--12-00, the only failures triggered by my
> >>> change are also the ones from the bpf-ci. Are these the ones you meant,
> >>> or am I missing some others?
> >>
> >> Multiple things broke at once so slightly hard to fish the relevant
> >> stuff out from here:
> >>
> >> https://netdev.bots.linux.dev/contest.html?branch=net-next-2026-01-05--15-00&pass=0&pw-n=0
> >>
> >> Here's one:
> >>
> >> make[1]: Entering directory 
> >> '/home/virtme/testing/wt-3/tools/testing/selftests/net'
> >>   CC       busy_poller
> >> In file included from [01m[K/usr/include/sys/socket.h:33[m[K,
> >>                  from [01m[K/usr/include/netinet/in.h:23[m[K,
> >>                  from [01m[K/usr/include/arpa/inet.h:22[m[K,
> >>                  from [01m[Kbusy_poller.c:14[m[K:
> >> [01m[K/usr/include/bits/socket.h:182:8:[m[K [01;31m[Kerror: 
> >> [m[Kredefinition of '[01m[Kstruct sockaddr[m[K'
> >
> >>                  from [01m[Kbusy_poller.c:12[m[K:
> >> [01m[K/home/virtme/testing/wt-3/usr/include/linux/socket.h:37:8:[m[K 
> >> [01;36m[Knote: [m[Koriginally defined here
> >
> > Maybe we can change all the instances of 'struct sockaddr' in
> > include/uapi/ to reference a new 'struct __kernel_sockaddr',
> > and then redirect that one if the libc header got included
> > first?
> >
> > struct __kernel_sockaddr {
> >        __kernel_sa_family_t    sa_family;      /* address family, AF_xxx       */
> >        char sa_data_min[14];           /* Minimum 14 bytes of protocol address */
> > };
> > #ifdef _SYS_SOCKET_H
> > #define __kernel_sockaddr sockaddr
> > #endif

I'm not a big fan of such a define in a generic header.

I do have a v2 of this patch currently in 0day. It reorders the inclusions
in the affected selftests. While it feels like a hack, interspersing the
different types of headers may already break randomly due to issues in
libc-compat.h (see below)

> > This will still fail when a user application includes linux/if.h
> > before sys/socket.h and then expects the structures in linux/if.h
> > to contain the libc version of sockaddr, but hopefully that is
> > much rarer. A survey of codesearch.debian.net shows almost all
> > users of linux/if.h first including sys/socket.h, and most of
> > them not caring about struct sockaddr either.

The whole linux/libc-compat.h machinery is brittle when UAPI headers are
included before libc headers. It will only detect the included libc headers
on its first inclusion. If overlapping libc and UAPI after that, they will
run into symbol clashes.

> If you call the data member sa_data just like glibc, it will only fail
> in C++, not C.  GCC considers the two definitions sufficiently
> equivalent (even though glibc adds a may_alias attribute to meet POSIX
> requirements), and duplicate definitions are permitted in C.

clang is not so lenient and will error out.

> C++ with modules will probably support duplicate definitions, too, but I
> haven't checked if it's possible to get this work with GCC 16.


Thomas

* Thomas Weißschuh:

>> If you call the data member sa_data just like glibc, it will only fail
>> in C++, not C.  GCC considers the two definitions sufficiently
>> equivalent (even though glibc adds a may_alias attribute to meet POSIX
>> requirements), and duplicate definitions are permitted in C.
>
> clang is not so lenient and will error out.

It seems it accepts it if you switch to C23 mode.

Thanks,
Florian

On Mon, Jan 12, 2026 at 02:25:25PM +0100, Florian Weimer wrote:
> * Thomas Weißschuh:
> 
> >> If you call the data member sa_data just like glibc, it will only fail
> >> in C++, not C.  GCC considers the two definitions sufficiently
> >> equivalent (even though glibc adds a may_alias attribute to meet POSIX
> >> requirements), and duplicate definitions are permitted in C.
> >
> > clang is not so lenient and will error out.
> 
> It seems it accepts it if you switch to C23 mode.

The currently supported baseline for UAPI headers is C90.
We can't really force userspace to switch here.


Thomas

* Thomas Weißschuh:

> On Mon, Jan 12, 2026 at 02:25:25PM +0100, Florian Weimer wrote:
>> * Thomas Weißschuh:
>> 
>> >> If you call the data member sa_data just like glibc, it will only fail
>> >> in C++, not C.  GCC considers the two definitions sufficiently
>> >> equivalent (even though glibc adds a may_alias attribute to meet POSIX
>> >> requirements), and duplicate definitions are permitted in C.
>> >
>> > clang is not so lenient and will error out.
>> 
>> It seems it accepts it if you switch to C23 mode.
>
> The currently supported baseline for UAPI headers is C90.
> We can't really force userspace to switch here.

Including libc and UAPI headers at the same time is still officially
unsupported, right?

We don't test for it, so lots of combinations do not work.

Thanks,
Florian

On Mon, Jan 5, 2026, at 09:25, Thomas Weißschuh wrote:
> Various UAPI headers reference 'struct sockaddr'. Currently the
> definition of this struct is pulled in from the libc header
> sys/socket.h. This is problematic as it introduces a dependency
> on a full userspace toolchain.
>
> Instead expose a custom but compatible definition of 'struct sockaddr'
> in the UAPI headers. It is guarded by the libc compatibility
> infrastructure to avoid potential conflicts.
>
> The compatibility symbol won't be supported by glibc right away,
> but right now __UAPI_DEF_IF_IFNAMSIZ is not supported either,
> so including the libc headers before the UAPI headers is broken anyways.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

This looks like the right approach to me. I have previously
tried to introduce a 'struct __kernel_sockaddr' structure and
use that in uapi headers in place of the libc sockaddr, but
that seemed worse in the end, and introduce the same problems
as using the existing __kernel_sockaddr_storage.

The version that worked for my own testing used a nolibc specific
definition, which was enough for me to build-test the kernel headers
across all architectures, but it does not resolve the dependency.

What I'm not sure about is whether the added definition will
cause problems for users that include linux/socket.h (or one
of the headers using it) before including sys/socket.h.
I would expect that this causes build failures on some application
source code, but hopefully in a way that is easily fixable by
changing the include order.
I've added the libc-alpha list to Cc, along with a few
developers that care about this.

I also found a few older commits in which we've tried to work
this out in the past, but each time created a new (or old) problem:

57a87bb0720a ("[PATCH] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h")
304c209c9b02 ("[NET]: Revert socket.h/stat.h ifdef hacks.")
9c501935a3cd ("net: Support inclusion of <linux/socket.h> before <sys/socket.h>")
2618be7dccf8 ("uapi: fix linux/if.h userspace compilation errors")
22bbc1dcd0d6 ("vsock/uapi: fix linux/vm_sockets.h userspace compilation errors")
06e445f740c1 ("mptcp: fix conflict with <netinet/in.h>")
c11c5906bc0a ("mptcp: add MPTCP_SUBFLOW_ADDRS getsockopt support")

      Arnd

> ---
>  include/linux/socket.h           | 10 ----------
>  include/uapi/linux/if.h          |  4 ----
>  include/uapi/linux/libc-compat.h | 12 ++++++++++++
>  include/uapi/linux/socket.h      | 14 ++++++++++++++
>  4 files changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index ec715ad4bf25..8363d4e0a044 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -28,16 +28,6 @@ extern void socket_seq_show(struct seq_file *seq);
> 
>  typedef __kernel_sa_family_t	sa_family_t;
> 
> -/*
> - *	1003.1g requires sa_family_t and that sa_data is char.
> - */
> -
> -/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */
> -struct sockaddr {
> -	sa_family_t	sa_family;	/* address family, AF_xxx	*/
> -	char		sa_data[14];	/* 14 bytes of protocol address	*/
> -};
> -
>  /**
>   * struct sockaddr_unsized - Unspecified size sockaddr for callbacks
>   * @sa_family: Address family (AF_UNIX, AF_INET, AF_INET6, etc.)
> diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
> index 797ba2c1562a..a4bc54196a07 100644
> --- a/include/uapi/linux/if.h
> +++ b/include/uapi/linux/if.h
> @@ -25,10 +25,6 @@
>  #include <linux/socket.h>		/* for "struct sockaddr" et al	*/
>  #include <linux/compiler.h>		/* for "__user" et al           */
> 
> -#ifndef __KERNEL__
> -#include <sys/socket.h>			/* for struct sockaddr.		*/
> -#endif
> -
>  #if __UAPI_DEF_IF_IFNAMSIZ
>  #define	IFNAMSIZ	16
>  #endif /* __UAPI_DEF_IF_IFNAMSIZ */
> diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
> index 0eca95ccb41e..13a06ce4e825 100644
> --- a/include/uapi/linux/libc-compat.h
> +++ b/include/uapi/linux/libc-compat.h
> @@ -140,6 +140,13 @@
> 
>  #endif /* _NETINET_IN_H */
> 
> +/* Definitions for socket.h */
> +#if defined(_SYS_SOCKET_H)
> +#define __UAPI_DEF_SOCKADDR		0
> +#else
> +#define __UAPI_DEF_SOCKADDR		1
> +#endif
> +
>  /* Definitions for xattr.h */
>  #if defined(_SYS_XATTR_H)
>  #define __UAPI_DEF_XATTR		0
> @@ -221,6 +228,11 @@
>  #define __UAPI_DEF_IP6_MTUINFO		1
>  #endif
> 
> +/* Definitions for socket.h */
> +#ifndef __UAPI_DEF_SOCKADDR
> +#define __UAPI_DEF_SOCKADDR		1
> +#endif
> +
>  /* Definitions for xattr.h */
>  #ifndef __UAPI_DEF_XATTR
>  #define __UAPI_DEF_XATTR		1
> diff --git a/include/uapi/linux/socket.h b/include/uapi/linux/socket.h
> index d3fcd3b5ec53..35d7d5f4b1a8 100644
> --- a/include/uapi/linux/socket.h
> +++ b/include/uapi/linux/socket.h
> @@ -2,6 +2,8 @@
>  #ifndef _UAPI_LINUX_SOCKET_H
>  #define _UAPI_LINUX_SOCKET_H
> 
> +#include <linux/libc-compat.h>          /* for compatibility with glibc */
> +
>  /*
>   * Desired design of maximum size and alignment (see RFC2553)
>   */
> @@ -26,6 +28,18 @@ struct __kernel_sockaddr_storage {
>  	};
>  };
> 
> +/*
> + *	1003.1g requires sa_family_t and that sa_data is char.
> + */
> +
> +/* Deprecated for in-kernel use. Use struct sockaddr_unsized instead. */
> +#if __UAPI_DEF_SOCKADDR
> +struct sockaddr {
> +	__kernel_sa_family_t	sa_family;	/* address family, AF_xxx	*/
> +	char			sa_data[14];	/* 14 bytes of protocol address	*/
> +};
> +#endif /* __UAPI_DEF_SOCKADDR */
> +
>  #define SOCK_SNDBUF_LOCK	1
>  #define SOCK_RCVBUF_LOCK	2
> 
>
> ---
> base-commit: dbf8fe85a16a33d6b6bd01f2bc606fc017771465
> change-id: 20251222-uapi-sockaddr-cf10e7624729
>
> Best regards,
> -- 
> Thomas Weißschuh <thomas.weissschuh@linutronix.de>

On 2026-01-05 05:50, Arnd Bergmann wrote:
> 
> This looks like the right approach to me. I have previously
> tried to introduce a 'struct __kernel_sockaddr' structure and
> use that in uapi headers in place of the libc sockaddr, but
> that seemed worse in the end, and introduce the same problems
> as using the existing __kernel_sockaddr_storage.
> 

You say "the same problems". It's not clear to me what that means.

Based on my own libc experience, hacking both a minimal (klibc) and a
maximal (glibc) libc, there are a *lot* of advantages to having
__kernel_* definitions available, *regardless* of if they are exported
into the libc namespace at all.

Specifically:

1. When calling explicit kernel interfaces, like ioctl(), it is the
   kernel interfaces, not the libc interfaces, that needs to be
   used. However, the rest of the application may need to include the
   libc headers.

2. The libc *implementation* may need to have both the kernel and the
   libc interfaces available.

In the case of struct sockaddr et al, it probably matters less,
because it isn't practical for them to be different for other
reasons, but it has been a real problem for things like termios.

On the flipside, for things where the kernel interfaces are inherently
necessary, we really want the libc authors to be able to use the uapi
headers. However, they have to be concerned about things like
namespace restrictions.

So I have a very, very strong vote for using and even expanding the
use of __kernel_* in the uapi headers. In fact, it would even be nice
to have a variant of "make headers_install" that automatically
transmogrifies symbols; if it isn't doable with simple pattern
matching then perhaps using coccinelle.

Allowing the libc authors to modify those transmogrification rules
would definitely be better than having various kinds of header guards.

	-hpa

On Tue, Jan 20, 2026, at 19:50, H. Peter Anvin wrote:
> On 2026-01-05 05:50, Arnd Bergmann wrote:
>> 
>> This looks like the right approach to me. I have previously
>> tried to introduce a 'struct __kernel_sockaddr' structure and
>> use that in uapi headers in place of the libc sockaddr, but
>> that seemed worse in the end, and introduce the same problems
>> as using the existing __kernel_sockaddr_storage.
>> 
>
> You say "the same problems". It's not clear to me what that means.

I must have accidentally cut that from my reply, sorry.
Looking at it again now, I think I ran into problems with the
flexible array that was removed from the in-kernel sockaddr
structure in commit 2b5e9f9b7e41 ("net: Convert struct sockaddr
to fixed-size "sa_data[14]""), so there is a good chance it works
now with the (once more) fixed-size version.

The other problem is that the structures that embed 'sockaddr'
are used a lot inside of the kernel, in particular in 'ifreq',
so changing the uapi sockaddr to __kernel_sockaddr requires
additional changes wherever the struct members are passed
by reference.

> Based on my own libc experience, hacking both a minimal (klibc) and a
> maximal (glibc) libc, there are a *lot* of advantages to having
> __kernel_* definitions available, *regardless* of if they are exported
> into the libc namespace at all.

Absolutely, I am totally in agreement about this in general, which
is why I tried this approach first.

      Arnd

On 2026-01-20 14:31, Arnd Bergmann wrote:
>> 
> I must have accidentally cut that from my reply, sorry.
> Looking at it again now, I think I ran into problems with the
> flexible array that was removed from the in-kernel sockaddr
> structure in commit 2b5e9f9b7e41 ("net: Convert struct sockaddr
> to fixed-size "sa_data[14]""), so there is a good chance it works
> now with the (once more) fixed-size version.
> 
> The other problem is that the structures that embed 'sockaddr'
> are used a lot inside of the kernel, in particular in 'ifreq',
> so changing the uapi sockaddr to __kernel_sockaddr requires
> additional changes wherever the struct members are passed
> by reference.
>

Well, the kernel should do what opting-in libcs do:

#define sockaddr __kernel_sockaddr

or

struct sockaddr { struct __kernel_sockaddr; };

... now when we have ms extensions turned on. Unfortunately gcc/clang don't
support them without the option even with __extension__, so user space is
limited to using macros.

	-hpa

On Tue, Jan 20, 2026 at 03:20:18PM -0800, H. Peter Anvin wrote:
> On 2026-01-20 14:31, Arnd Bergmann wrote:
> >> 
> > I must have accidentally cut that from my reply, sorry.
> > Looking at it again now, I think I ran into problems with the
> > flexible array that was removed from the in-kernel sockaddr
> > structure in commit 2b5e9f9b7e41 ("net: Convert struct sockaddr
> > to fixed-size "sa_data[14]""), so there is a good chance it works
> > now with the (once more) fixed-size version.
> > 
> > The other problem is that the structures that embed 'sockaddr'
> > are used a lot inside of the kernel, in particular in 'ifreq',
> > so changing the uapi sockaddr to __kernel_sockaddr requires
> > additional changes wherever the struct members are passed
> > by reference.
> >
> 
> Well, the kernel should do what opting-in libcs do:
> 
> #define sockaddr __kernel_sockaddr

This looks reasonable, but would only apply to future libc releases, no?

Adopting a new scheme for all types will be a larger undertaking. Today
'struct sockaddr' is the only type not using the current compatibility
mechanism. Could we first align 'struct sockaddr' as shown by the patch?
Whatever comes next can then build on a uniform base.

> or
> 
> struct sockaddr { struct __kernel_sockaddr; };
> 
> ... now when we have ms extensions turned on. Unfortunately gcc/clang don't
> support them without the option even with __extension__, so user space is
> limited to using macros.


Thomas