On Tue, Jan 20, 2026, at 19:50, H. Peter Anvin wrote:

On 2026-01-05 05:50, Arnd Bergmann wrote:

quoted

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