include/linux/socket.h | 10 ---------- include/uapi/linux/if.h | 4 ---- include/uapi/linux/libc-compat.h | 12 ++++++++++++ include/uapi/linux/socket.h | 14 ++++++++++++++ samples/bpf/xdp_adjust_tail_user.c | 6 ++++-- samples/bpf/xdp_fwd_user.c | 7 ++++--- samples/bpf/xdp_router_ipv4_user.c | 6 +++--- samples/bpf/xdp_sample_user.c | 15 ++++++++------- samples/bpf/xdp_tx_iptunnel_user.c | 4 ++-- tools/testing/selftests/landlock/audit.h | 7 ++++--- tools/testing/selftests/net/af_unix/diag_uid.c | 9 +++++---- tools/testing/selftests/net/busy_poller.c | 3 ++- tools/testing/selftests/net/mptcp/mptcp_diag.c | 11 ++++++----- tools/testing/selftests/net/nettest.c | 4 ++-- tools/testing/selftests/net/tcp_ao/icmps-discard.c | 6 +++--- tools/testing/selftests/net/tcp_ao/lib/netlink.c | 9 +++++---- tools/testing/selftests/net/tun.c | 5 +++-- 17 files changed, 77 insertions(+), 55 deletions(-)
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.
Add a definition of 'struct sockaddr' to the UAPI headers.
Before that, reorder some problematic header inclusions in the selftests.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Changes in v2:
- Fix compilation failures in BPF samples and selftests
- Link to v1: https://lore.kernel.org/r/20260105-uapi-sockaddr-v1-1-b7653aba12a5@linutronix.de
---
Thomas Weißschuh (4):
selftests: net: Move some UAPI header inclusions after libc ones
selftests/landlock: Move some UAPI header inclusions after libc ones
samples/bpf: Move some UAPI header inclusions after libc ones
net: uapi: Provide an UAPI definition of 'struct sockaddr'
include/linux/socket.h | 10 ----------
include/uapi/linux/if.h | 4 ----
include/uapi/linux/libc-compat.h | 12 ++++++++++++
include/uapi/linux/socket.h | 14 ++++++++++++++
samples/bpf/xdp_adjust_tail_user.c | 6 ++++--
samples/bpf/xdp_fwd_user.c | 7 ++++---
samples/bpf/xdp_router_ipv4_user.c | 6 +++---
samples/bpf/xdp_sample_user.c | 15 ++++++++-------
samples/bpf/xdp_tx_iptunnel_user.c | 4 ++--
tools/testing/selftests/landlock/audit.h | 7 ++++---
tools/testing/selftests/net/af_unix/diag_uid.c | 9 +++++----
tools/testing/selftests/net/busy_poller.c | 3 ++-
tools/testing/selftests/net/mptcp/mptcp_diag.c | 11 ++++++-----
tools/testing/selftests/net/nettest.c | 4 ++--
tools/testing/selftests/net/tcp_ao/icmps-discard.c | 6 +++---
tools/testing/selftests/net/tcp_ao/lib/netlink.c | 9 +++++----
tools/testing/selftests/net/tun.c | 5 +++--
17 files changed, 77 insertions(+), 55 deletions(-)
---
base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
change-id: 20251222-uapi-sockaddr-cf10e7624729
Best regards,
--
Thomas Weißschuh <thomas.weissschuh@linutronix.de>
On Tue, 20 Jan 2026 15:10:30 +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. > > Add a definition of 'struct sockaddr' to the UAPI headers. > Before that, reorder some problematic header inclusions in the selftests. > include/linux/socket.h | 10 ---------- > include/uapi/linux/if.h | 4 ---- > include/uapi/linux/libc-compat.h | 12 ++++++++++++ > include/uapi/linux/socket.h | 14 ++++++++++++++ > samples/bpf/xdp_adjust_tail_user.c | 6 ++++-- > samples/bpf/xdp_fwd_user.c | 7 ++++--- > samples/bpf/xdp_router_ipv4_user.c | 6 +++--- > samples/bpf/xdp_sample_user.c | 15 ++++++++------- > samples/bpf/xdp_tx_iptunnel_user.c | 4 ++-- > tools/testing/selftests/landlock/audit.h | 7 ++++--- > tools/testing/selftests/net/af_unix/diag_uid.c | 9 +++++---- > tools/testing/selftests/net/busy_poller.c | 3 ++- > tools/testing/selftests/net/mptcp/mptcp_diag.c | 11 ++++++----- > tools/testing/selftests/net/nettest.c | 4 ++-- > tools/testing/selftests/net/tcp_ao/icmps-discard.c | 6 +++--- > tools/testing/selftests/net/tcp_ao/lib/netlink.c | 9 +++++---- > tools/testing/selftests/net/tun.c | 5 +++-- > 17 files changed, 77 insertions(+), 55 deletions(-) Are all those selftests / samples getting broken by this patch set? I understand that we should avoid libc dependencies in uAPI but at least speaking for networking - building selftests without libc is.. not a practical proposition?
On Wed, Jan 21, 2026 at 07:27:29PM -0800, Jakub Kicinski wrote: > On Tue, 20 Jan 2026 15:10:30 +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. > > > > Add a definition of 'struct sockaddr' to the UAPI headers. > > Before that, reorder some problematic header inclusions in the selftests. > > > include/linux/socket.h | 10 ---------- > > include/uapi/linux/if.h | 4 ---- > > include/uapi/linux/libc-compat.h | 12 ++++++++++++ > > include/uapi/linux/socket.h | 14 ++++++++++++++ > > samples/bpf/xdp_adjust_tail_user.c | 6 ++++-- > > samples/bpf/xdp_fwd_user.c | 7 ++++--- > > samples/bpf/xdp_router_ipv4_user.c | 6 +++--- > > samples/bpf/xdp_sample_user.c | 15 ++++++++------- > > samples/bpf/xdp_tx_iptunnel_user.c | 4 ++-- > > tools/testing/selftests/landlock/audit.h | 7 ++++--- > > tools/testing/selftests/net/af_unix/diag_uid.c | 9 +++++---- > > tools/testing/selftests/net/busy_poller.c | 3 ++- > > tools/testing/selftests/net/mptcp/mptcp_diag.c | 11 ++++++----- > > tools/testing/selftests/net/nettest.c | 4 ++-- > > tools/testing/selftests/net/tcp_ao/icmps-discard.c | 6 +++--- > > tools/testing/selftests/net/tcp_ao/lib/netlink.c | 9 +++++---- > > tools/testing/selftests/net/tun.c | 5 +++-- > > 17 files changed, 77 insertions(+), 55 deletions(-) > > Are all those selftests / samples getting broken by this patch set? Yes. Some of them get broken by the new 'struct sockaddr', but some others are already broken just by the new transitive inclusion of libc-compat.h. So any header starting to use the compatibility machinery may trigger breakage in code including UAPI headers before libc header, even for completely new type definitions which themselves would not conflict with libc. > I understand that we should avoid libc dependencies in uAPI but at > least speaking for networking - building selftests without libc is.. > not a practical proposition? I am not sure I understand. Some sort of libc will always be necessary. And as the selftests are intended to exercise the low-level kernel APIs, even those not supported by libc, the UAPI headers will also be necessary. There is nolibc (tools/include/nolibc/) which is using the UAPI headers in most cases, and aims to be compatible. And can be and already is used for selftests, but it will be too limited for all of the networking selftests. (Disclaimer: I am maintaining nolibc) My goal is *not* to make the different headers less compatible on purpose. But by removing the existing dependencies we can now enforce the checks in CONFIG_UAPI_HEADER_TEST to prevent any new ones from creeping in. Therefore preventing compatiblity issues in any new UAPI. Thomas
On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote: > > Are all those selftests / samples getting broken by this patch set? > > Yes. > > Some of them get broken by the new 'struct sockaddr', but some others are > already broken just by the new transitive inclusion of libc-compat.h. > So any header starting to use the compatibility machinery may trigger breakage > in code including UAPI headers before libc header, even for completely new type > definitions which themselves would not conflict with libc. Let's split the uAPI header changes from any selftest changes. If you're saying the the selftests no longer build after the uAPI header changes then of course we can't apply the patches.
Jan 30, 2026 17:17:46 Jakub Kicinski <kuba@kernel.org>: > On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote: >>> Are all those selftests / samples getting broken by this patch set? >> >> Yes. >> >> Some of them get broken by the new 'struct sockaddr', but some others are >> already broken just by the new transitive inclusion of libc-compat.h. >> So any header starting to use the compatibility machinery may trigger breakage >> in code including UAPI headers before libc header, even for completely new type >> definitions which themselves would not conflict with libc. > > Let's split the uAPI header changes from any selftest changes. > If you're saying the the selftests no longer build after the uAPI > header changes then of course we can't apply the patches. Yes, the selftests don't build anymore after the uAPI changes. "can't apply" as in * "can't apply separately" * "are unacceptable in general" * "are too late for this cycle" ? None of this is urgent. We can do the selftests in one cycle and the uAPI in another one. Feel free to pick up the patches as you see fit. (The mptcp changes already go through their tree, so need to be dropped here) I can also resubmit the patches differently if preferred. Thomas
On Sat, 31 Jan 2026 11:26:32 +0100 Thomas Weißschuh wrote: > Jan 30, 2026 17:17:46 Jakub Kicinski <kuba@kernel.org>: > > > On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote: > >> Some of them get broken by the new 'struct sockaddr', but some others are > >> already broken just by the new transitive inclusion of libc-compat.h. > >> So any header starting to use the compatibility machinery may trigger breakage > >> in code including UAPI headers before libc header, even for completely new type > >> definitions which themselves would not conflict with libc. > > > > Let's split the uAPI header changes from any selftest changes. > > If you're saying the the selftests no longer build after the uAPI > > header changes then of course we can't apply the patches. > > Yes, the selftests don't build anymore after the uAPI changes. > > "can't apply" as in > * "can't apply separately" > * "are unacceptable in general" this one > * "are too late for this cycle" > ? > > None of this is urgent. > We can do the selftests in one cycle and the uAPI in another one. > Feel free to pick up the patches as you see fit. > (The mptcp changes already go through their tree, so need to be dropped here) > I can also resubmit the patches differently if preferred. The selftests are just a canary in the coalmine. If we break a bunch of selftests chances are we'll also break compilation of real applications for people. Subjective, but I don't see a sufficient upside here to do that. FWIW the typelimits change broke compilation of ethtool, we'll see if anyone "outside kernel community itself" complains.
On Sat, Jan 31, 2026 at 09:25:17AM -0800, Jakub Kicinski wrote: > On Sat, 31 Jan 2026 11:26:32 +0100 Thomas Weißschuh wrote: > > Jan 30, 2026 17:17:46 Jakub Kicinski <kuba@kernel.org>: > > > > > On Fri, 30 Jan 2026 11:34:15 +0100 Thomas Weißschuh wrote: > > >> Some of them get broken by the new 'struct sockaddr', but some others are > > >> already broken just by the new transitive inclusion of libc-compat.h. > > >> So any header starting to use the compatibility machinery may trigger breakage > > >> in code including UAPI headers before libc header, even for completely new type > > >> definitions which themselves would not conflict with libc. > > > > > > Let's split the uAPI header changes from any selftest changes. > > > If you're saying the the selftests no longer build after the uAPI > > > header changes then of course we can't apply the patches. > > > > Yes, the selftests don't build anymore after the uAPI changes. > > > > "can't apply" as in > > * "can't apply separately" > > * "are unacceptable in general" > > this one > > > * "are too late for this cycle" > > ? > > > > None of this is urgent. > > We can do the selftests in one cycle and the uAPI in another one. > > Feel free to pick up the patches as you see fit. > > (The mptcp changes already go through their tree, so need to be dropped here) > > I can also resubmit the patches differently if preferred. > > The selftests are just a canary in the coalmine. If we break a bunch of > selftests chances are we'll also break compilation of real applications > for people. Subjective, but I don't see a sufficient upside here to do > that. Okay. We'll have around this inconsistency then. > FWIW the typelimits change broke compilation of ethtool, we'll see if > anyone "outside kernel community itself" complains. Can you point me to that breakage? I was unable to find it. Thomas
On Tue, 3 Feb 2026 12:42:22 +0100 Thomas Weißschuh wrote:
> > FWIW the typelimits change broke compilation of ethtool, we'll see if
> > anyone "outside kernel community itself" complains.
>
> Can you point me to that breakage? I was unable to find it.
Not reported on the ML, and it's kinda annoying to repro because
the uAPI header sync script isn't committed :/ You have to check
this out
https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/
and run a script like this to sync headers from the kernel (then build):
#!/bin/bash -e
sn="${0##*/}"
export ARCH="x86_64"
if [ ! -d "$LINUX_GIT" ]; then
echo "${sn}: LINUX_GIT not set" >&2
exit 1
fi
pushd "$LINUX_GIT"
if [ -n "$1" ]; then
git checkout "$1"
fi
desc=$(git describe --exact-match 2>/dev/null \
|| git show -s --abbrev=12 --pretty='commit %h')
kobj=$(mktemp -d)
make -j16 O="$kobj" allmodconfig
make -j16 O="$kobj" prepare
make -j16 O="$kobj" INSTALL_HDR_PATH="${kobj}/hdr" headers_install
popd
pushd uapi
find . -type f -name '*.h' -exec cp -v "${kobj}/hdr/include/{}" {} \;
popd
rm -rf "$kobj"
git add uapi
git commit -s -F - <<EOT
update UAPI header copies
Update to kernel ${desc}.
EOT
On Tue, Feb 03, 2026 at 02:40:11PM -0800, Jakub Kicinski wrote:
> On Tue, 3 Feb 2026 12:42:22 +0100 Thomas Weißschuh wrote:
> > > FWIW the typelimits change broke compilation of ethtool, we'll see if
> > > anyone "outside kernel community itself" complains.
> >
> > Can you point me to that breakage? I was unable to find it.
>
> Not reported on the ML, and it's kinda annoying to repro because
> the uAPI header sync script isn't committed :/ You have to check
> this out
>
> https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/
>
> and run a script like this to sync headers from the kernel (then build):
>
> #!/bin/bash -e
>
> sn="${0##*/}"
> export ARCH="x86_64"
>
> if [ ! -d "$LINUX_GIT" ]; then
> echo "${sn}: LINUX_GIT not set" >&2
> exit 1
> fi
>
> pushd "$LINUX_GIT"
> if [ -n "$1" ]; then
> git checkout "$1"
> fi
> desc=$(git describe --exact-match 2>/dev/null \
> || git show -s --abbrev=12 --pretty='commit %h')
> kobj=$(mktemp -d)
> make -j16 O="$kobj" allmodconfig
> make -j16 O="$kobj" prepare
These are not necessary.
The UAPI generation does not need a kernel configuration.
> make -j16 O="$kobj" INSTALL_HDR_PATH="${kobj}/hdr" headers_install
> popd
>
> pushd uapi
> find . -type f -name '*.h' -exec cp -v "${kobj}/hdr/include/{}" {} \;
Here only those headers which already exist in ethtool's uapi/ directory
are copied. As linux/typelimits.h is new, it is now missing.
Honestly, if a user fiddles with the internals of the UAPI headers like
this, it is on them to update their code if the internal structure
changes. In your case a simple 'touch uapi/linux/typelimits.h'
before running the script will be enough. Also internal.h now requires
an explicit inclusion of <limits.h>, as that is not satisfied by the
UAPI anymore.
> popd
> rm -rf "$kobj"
>
> git add uapi
> git commit -s -F - <<EOT
> update UAPI header copies
>
> Update to kernel ${desc}.
>
> EOT
On Wed, 4 Feb 2026 06:51:46 +0100 Thomas Weißschuh wrote:
> > make -j16 O="$kobj" INSTALL_HDR_PATH="${kobj}/hdr" headers_install
> > popd
> >
> > pushd uapi
> > find . -type f -name '*.h' -exec cp -v "${kobj}/hdr/include/{}" {} \;
>
> Here only those headers which already exist in ethtool's uapi/ directory
> are copied. As linux/typelimits.h is new, it is now missing.
> Honestly, if a user fiddles with the internals of the UAPI headers like
> this, it is on them to update their code if the internal structure
> changes. In your case a simple 'touch uapi/linux/typelimits.h'
> before running the script will be enough. Also internal.h now requires
> an explicit inclusion of <limits.h>, as that is not satisfied by the
> UAPI anymore.
Hopefully you understand that while due to uapi header copy this is not
a huge issue for ethtool itself, but it is a proof that your changes
can break normal user space applications which do not vendor in uapi.
© 2016 - 2026 Red Hat, Inc.