Re: [PATCH bpf] libbpf: fix reuse of pinned map on older kernel

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

 



On Wed, Jul 7, 2021 at 3:36 AM Martynas Pumputis <m@xxxxxxxxx> wrote:
>
>
>
> On 7/7/21 1:32 AM, Song Liu wrote:
> > On Tue, Jul 6, 2021 at 10:24 AM Martynas Pumputis <m@xxxxxxxxx> wrote:
> >>
> >> When loading a BPF program with a pinned map, the loader checks whether
> >> the pinned map can be reused, i.e. their properties match. To derive
> >> such of the pinned map, the loader invokes BPF_OBJ_GET_INFO_BY_FD and
> >> then does the comparison.
> >>
> >> Unfortunately, on < 4.12 kernels the BPF_OBJ_GET_INFO_BY_FD is not
> >> available, so loading the program fails with the following error:
> >>
> >>          libbpf: failed to get map info for map FD 5: Invalid argument
> >>          libbpf: couldn't reuse pinned map at
> >>                  '/sys/fs/bpf/tc/globals/cilium_call_policy': parameter
> >>                  mismatch"
> >>          libbpf: map 'cilium_call_policy': error reusing pinned map
> >>          libbpf: map 'cilium_call_policy': failed to create:
> >>                  Invalid argument(-22)
> >>          libbpf: failed to load object 'bpf_overlay.o'
> >>
> >> To fix this, probe the kernel for BPF_OBJ_GET_INFO_BY_FD support. If it
> >> doesn't support, then fallback to derivation of the map properties via
> >> /proc/$PID/fdinfo/$MAP_FD.
> >>
> >> Signed-off-by: Martynas Pumputis <m@xxxxxxxxx>
> >
> > The code looks good to me. Except a checkpatch CHECK:
> >
> > CHECK: Comparison to NULL could be written "!obj"
> > #96: FILE: tools/lib/bpf/libbpf.c:3943:
> > + if (obj == NULL || kernel_supports(obj, FEAT_OBJ_GET_INFO_BY_FD))
>
> Thanks for the review. I will send v2 with the fix.
>
> >
> > Also, I think this should target bpf-next tree?
>
> Considering that libbpf is supported on older kernels, w/o this patch it
> is impossible to use it on < 4.12 kernels for programs with pinned maps.
> Therefore, I think that this is a fix and thus it should target the bpf
> tree instead.

It does feel like a feature of supporting even older kernels. There
was nothing broken before, libbpf just didn't know how to get
information to validate map info. Now it knows how to do it for older
kernels. So I'd still route it through bpf-next tree.

>
> >
> > Thanks,
> > Song
> >



[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