On Wed, Oct 26, 2022 at 01:27:49AM +0300, Eduard Zingerman wrote:
>
> Include the following system header:
> - /usr/include/sys/socket.h (all via linux/if.h)
>
> The sys/socket.h conflicts with vmlinux.h in:
> - types: struct iovec, struct sockaddr, struct msghdr, ...
> - constants: SOCK_STREAM, SOCK_DGRAM, ...
>
> However, only two types are actually used:
> - struct sockaddr
> - struct sockaddr_storage (used only in linux/mptcp.h)
>
> In 'vmlinux.h' this type originates from 'kernel/include/socket.h'
> (non UAPI header), thus does not have a header guard.
>
> The only workaround that I see is to:
> - define a stub sys/socket.h as follows:
>
> #ifndef __BPF_SOCKADDR__
> #define __BPF_SOCKADDR__
>
> /* For __kernel_sa_family_t */
> #include <linux/socket.h>
>
> struct sockaddr {
> __kernel_sa_family_t sa_family;
> char sa_data[14];
> };
>
> #endif
>
> - hardcode generation of __BPF_SOCKADDR__ bracket for
> 'struct sockaddr' in vmlinux.h.
we don't need to hack sys/socket.h and can hardcode
#ifdef _SYS_SOCKET_H as header guard for sockaddr instead, right?
bits/socket.h has this:
#ifndef _SYS_SOCKET_H
# error "Never include <bits/socket.h> directly; use <sys/socket.h> instead."
So that ifdef is kinda stable.
> Another possibility is to move the definition of 'struct sockaddr'
> from 'kernel/include/socket.h' to 'kernel/include/uapi/linux/socket.h',
> but I expect that this won't fly with the mainline as it might break
> the programs that include both 'linux/socket.h' and 'sys/socket.h'.
>
> Conflict with vmlinux.h
> ----
>
> Uapi header:
> - linux/signal.h
>
> Conflict with vmlinux.h in definition of 'struct sigaction'.
> Defined in:
> - vmlinux.h: kernel/include/linux/signal_types.h
> - uapi: kernel/arch/x86/include/asm/signal.h
>
> Uapi headers:
> - linux/tipc_sockets_diag.h
> - linux/sock_diag.h
>
> Conflict with vmlinux.h in definition of 'SOCK_DESTROY'.
Interesting one!
I think we can hard code '#undef SOCK_DESTROY' in vmlinux.h
The goal is not to be able to mix arbitrary uapi header with
vmlinux.h, but only those that could be useful out of bpf progs.
Currently it's tcp.h and few other network related headers
because they have #define-s in them that are useful inside bpf progs.
As long as the solution covers this small subset we're fine.
