Re: libbpf/bpftool inconsistent handling og .data and .bss ?

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Wed, Oct 7, 2020 at 9:03 AM Luigi Rizzo <rizzo@iet.unipi.it> wrote:
>
> I am experiencing some weirdness in global variables handling
> in bpftool and libbpf, as described below.
>
> This happens happen with code in foo_bpf.c compiled with
>    clang-10 -O2 -Wall -Werror -target bpf ...
> and subsequently exported with
>    bpftool gen skeleton ...
> (i have tried bpftool 5.8.7 and 5.9.0-rc6)
>
> 1. uninitialized globals are not recognised
>    The following code in the bpf program
>
>      int x;
>      SEC("fentry/bar")
>      int BPF_PROG(bar) { return 0;}
>
>    compiles ok but bpftool then complains
>
>       libbpf: prog 'bar': invalid relo against 'x' in special section
> 0xfff2; forgot to initialize global var?..
>
>    The error disappears if I initialize x=0 or x=1
>    (in the skeleton, x=0 ends up in .bss, x=1 ends up in .data)

Yonghong addressed this. Just zero-initialize them.

>
> 2. .bss overrides from userspace are not seen in bpf at runtime
>
>     In foo_bpf.c I have "int x = 0;"
>     In the userspace program, before foo_bpf__load(), I do
>        obj->bss->x = 1
>     but after attach, the bpf code does not see the change, ie
>         "if (x == 0) { .. } else { .. }"
>     always takes the first branch.
>
>     If I initialize "int x = 2" and then do
>        obj->data->x = 1
>     the update is seen correctly ie
>           "if (x == 2) { .. } else { .. }"
>      takes one or the other depending on whether userspace overrides
>      the value before foo_bpf__load()

This is quite surprising, given we have explicit selftests validating
that all this works. And it seems to work. Please check
prog_tests/skeleton.c and progs/test_skeleton.c. Can you try running
it and confirm that it works in your setup?


>
> 3. .data overrides do not seem to work for non-scalar types
>     In foo_bpf.c I have
>           struct one { int a; }; // type also visible to userspace
>           struct one x { .a = 2 }; // avoid bugs #1 and #2
>     If in userspace I do
>           obj->data->x.a = 1
>     the update is not seen in the kernel, ie
>             "if (x.a == 2) { .. } else { .. }"
>      always takes the first branch
>

Similarly, the same skeleton selftest tests this situation. So please
check selftests first and report if selftests for some reason don't
work in your case.

> Are these known issues ?
>
> thanks
> luigi