* Arnd Bergmann:

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

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