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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Oct 10, 2020 at 5:31 PM Luigi Rizzo <lrizzo@xxxxxxxxxx> wrote:
>
> On Sun, Oct 11, 2020 at 1:11 AM Andrii Nakryiko
> <andrii.nakryiko@xxxxxxxxx> wrote:
> >
> > On Sat, Oct 10, 2020 at 3:49 PM Luigi Rizzo <lrizzo@xxxxxxxxxx> wrote:
> > >
> > > Coming back to .bss handling:
> > >
> > > On Wed, Oct 7, 2020 at 11:29 PM Luigi Rizzo <lrizzo@xxxxxxxxxx> wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 10:40 PM Andrii Nakryiko
> > > > <andrii.nakryiko@xxxxxxxxx> wrote:
> > > > >
> > > > > On Wed, Oct 7, 2020 at 1:31 PM Luigi Rizzo <lrizzo@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > TL;DR; there seems to be a compiler bug with clang-10 and -O2
> > > > > > when struct are in .data -- details below.
> > > > > >
> > > > > > On Wed, Oct 7, 2020 at 8:35 PM Andrii Nakryiko
> > > > > > <andrii.nakryiko@xxxxxxxxx> wrote:
> > > > > > >
> > > > > > > On Wed, Oct 7, 2020 at 9:03 AM Luigi Rizzo <rizzo@xxxxxxxxxxxx> wrote:
> > > > > > ...
> > > > > > > > 2. .bss overrides from userspace are not seen in bpf at runtime
> > > ...
> > > > > > >
> > > > > > > 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?
> > > > > >
> > > > > > Ah, this was non intuitive but obvious in hindsight:
> > > > > >
> > > > > > .bss is zeroed by the kernel after load(), and since my program
> > > > > > changed the value before foo_bpf__load() , the memory was overwritten
> > > > > > with 0s. I could confirm this by printing the value after load.
> > > > > >
> > > > > > If I update obj->data-><something> after __load(),
> > > > > > or even after __attach() given that userspace mmaps .bss and .data,
> > > > > > everything works as expected both for scalars and structs.
> > > > >
> > > > > Check prog_tests/skeleton.c again, it sets .data, .bss, and .rodata
> > > > > before the load. And checks that those values are preserved after
> > > > > load. So .bss, if you initialize it manually, shouldn't zero-out what
> > > > > you set.
> > >
> > > strace reveals that the .bss is initially created as anonymous memory:
> > >
> > >   mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1,
> > > 0) = 0x7fd074a5f000
> > >   write(2, "after open bss is at 0x7fd074a5f"..., 36after open bss is
> > > at 0x7fd074a5f000) = 36
> > >
> > > and then remapped after the map has been created:
> > >   bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4,
> > > value_size=144,  max_entries=1, map_flags=0x400 /* BPF_F_??? */,
> > > inner_map_fd=0, map_name="hstats_b.bss", map_ifindex=0, ...}, 120) = 6
> > >   ...
> > >   mmap(0x7fd074a5f000, 4096, PROT_READ|PROT_WRITE,
> > > MAP_SHARED|MAP_FIXED, 6, 0) = 0x7fd074a5f000
> > >
> > > so the original content is gone.
> >
> > not exactly, all of .bss, .rodata, .data and .kconfig are first
> > mmap()'ed as anonymous memory. I've modified test_skeleton.c to
> > increase .bss size to 8192 bytes size to distinguish it from other
> > maps:
> >
> > 1. mmap() anonymous memory (just allocating memory that would keep
> > initial values that you set with skel->bss->my_var = 123):
> >
> > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1,
> > 0) = 0x7fb3b406f000
> >
> > 2. use that anonymous memory with initialized variables to update map
> > contents during bpf_object's load:
> >
> > bpf(BPF_MAP_UPDATE_ELEM, {map_fd=7, key=0x7ffdab521d50,
> > value=0x7fb3b406f000, flags=BPF_ANY}, 120) = 0
>
> I do not see this BPF_MAP_UPDATE_ELEM for the .bss segment in my strace.
> What I see (repeated at the end) is that the .bss map is
> created and then just remapped as you indicate below in #3
>
> Maybe this was added in a more recent version of the library
> than the one I have?
>
> $ apt info libbpf-dev
> Package: libbpf-dev
> Version: 1:0.0.8-1

Your version is almost 3 full releases behind. Yes, this was fixed a
long time ago. Please update your libbpf.

> Priority: optional
> Section: libdevel
> Source: libbpf (0.0.8-1)
>
>
> cheers
> luigi



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux