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

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

 



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.

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