Re: [PATCH net-next] net: uapi: Provide an UAPI definition of 'struct sockaddr'

On Mon, Jan 12, 2026 at 12:42:17PM +0100, Florian Weimer wrote:

* Arnd Bergmann:

quoted

On Wed, Jan 7, 2026, at 00:13, Jakub Kicinski wrote:

quoted

On Tue, 6 Jan 2026 11:32:52 +0100 Thomas Weißschuh wrote:

quoted

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'

quoted

                 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)

quoted

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