Message-ID: <20220829175413.h2335oivqcg34pw3@kafai-mbp.dhcp.thefacebook.com>
Date:   Mon, 29 Aug 2022 10:54:13 -0700
From:   Martin KaFai Lau <kafai@...com>
To:     "Jose E. Marchesi" <jose.marchesi@...cle.com>
Cc:     James Hilliard <james.hilliard1@...il.com>, bpf@...r.kernel.org,
        Andrii Nakryiko <andrii@...nel.org>,
        Mykola Lysenko <mykolal@...com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/bpf: Fix bind{4,6} tcp/socket header type
 conflict

On Sat, Aug 27, 2022 at 03:13:41AM +0200, Jose E. Marchesi wrote:
> >> Users can migrate away from libc headers over time, migrating away
> > imo, not without a good reason.
> 
> Something that may be a good reason is that there is no BPF port of
> glibc (nor of musl, nor of newlib.)  And given BPF's restrictions as an
> architecture (no more than 5 arguments supported in function calls, etc)
> it is very unlikely that there will ever be one.
> 
> Including certain libc headers may work well enough, but in general when
> including libc headers you risk dragging in x86, or aarch64, or whatever
> architecture-specific headers as well, directly or indirectly.  C
> libraries (and system libraries in general) are targetted at particular
> architectures/ABIs/OSes.
> 
> This means that the same BPF program may be using different data
> structures depending on the system where you build it.
Note that the data structure difference is not unique to
different arch.  A more common case can already happen across
different kernel versions or different kconfig of the same arch.
BPF CO-RE is there to handle this case.

> In the worst
> case, it may choke on assembler snippets.
> 
> Thats why the GCC port offers certain headers to provide standard C,
> like stdint.h.  That's the usual way to go for bare-metal targets where
> no libc is available.
> 
> Again, we will be happy to change that if that's what you want.  In that
> case, it will be up to the user to provide the standard definitions, be
> it by including glibc headers targetted at some other architecture, or
> by some other mean.  Not that I would personally recommend that, but it
> is up to you.
Not sure if the user can always stay with vmlinux.h + a few bpf_tracing_*.h
and if that is enough to avoid knowing this difference between GCC
and LLVM bpf on libc-vs-gcc stdint...etc.

The header changes is hard to swim through to make it compile
in GCC BPF.  In this case, it is because netinet/tcp.h brought in a
different int8_t from gcc than the sys/socket.h.  My preference is
not to have to dive into this kind of header details.
I would like to hear how others think about it.

> >
> >> shouldn't cause regressions and should improve reliability.
> > May be I am missing something.  I also don't understand the reliability
> > part.
> >
> > In this sys/socket.h as an example, what is wrong in using
> > "'int8_t' {aka 'signed char'}" from libc and the one from
> > gcc "'int8_t'; have 'char'" must be used instead.
> >
> > Why LLVM bpf does not have issue ?
> >
> >> 
> >> > The solution should be on the GCC-BPF side instead of changing
> >> > all bpf progs.
> >> 
> >> I mean, GCC doesn't really control which libc is available, it seems to
> >> be a bad idea to use libc headers in general as they are developed
> >> separately from GCC and the kernel/libbpf.
> >> 
> >> I'm not really sure how one would fix this on the GCC-BPF side without
> >> introducing more potential header conflicts.

Powered by blists - more mailing lists