Re: Interesting data corruption in bpf_object_open_opts

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

 



On Fri, Sep 23, 2022 at 3:24 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Tue, Sep 13, 2022 at 6:23 PM Grant Seltzer Richman
> <grantseltzer@xxxxxxxxx> wrote:
> >
> > Hi all, I'm experiencing an issue that I want to discuss, though I'm
> > not sure libbpf code is at fault. Any guidance is much appreciated.
> >
> > The behavior I'm seeing is that I have a `struct bpf_object_open_opts`
> > where I properly set each of the `btf_custom_path` and `kconfig`
> > fields. I then call `bpf_object__open_mem` with this opts struct and
> > get this error:
> >
> > libbpf: failed to get EHDR from /proc/config.gz
> >
> > The very important thing to note here is that I'm setting the fields
> > and calling bpf_object__open_mem from Go code using CGO (this is in
> > libbpfgo). I do believe it's likely to be a CGO issue and not libbpf
> > itself, but here's why:
> >
> > I've `git bisect`'ed the issue to be caused by commit `d8454ba8`,
> > which leads me to believe that CGO is failing to adjust offsets for
> > whatever having `long :0` in bpf_object_open_opts does. I can't figure
> > out why this was added, what exactly does that do? Is it some type of
> > added padding? Is it possible this isn't CGO?
>
> Yes, the intent was to have a hole between pin_root_path and kconfig.
> But this is a bug, my commit actually changed the layout of
> bpf_object_open_opts, unintentionally, because if long: 0 is already
> at long-aligned offset (which it is in this case) it does nothing,
> instead of shifting next field to next long-aligned offset. So
> bpf_object_open_opts is basically broken in libbpf 1.0. Thanks for the
> report! I'll send a fix shortly and we'll need to release 1.0.1 bug
> fix release.
>

Ok, so this should be fixed in [0]. But also note that technically you
are required to recompile with libbpf 1.0 header if you are linking
against libbpf.so.1. In your case it appears as your headers and
actual .so library was from 0.x and 1.x. So check that as well.

  [0] https://patchwork.kernel.org/project/netdevbpf/patch/20220923230559.666608-1-andrii@xxxxxxxxxx/

> >
> > Thanks for any help,
> > Grant



[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