lkml.org 
[lkml]   [2022]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 5.15 000/846] 5.15.17-rc1 review
    On Mon, Jan 24, 2022 at 12:36 PM Holger Hoffstätte
    <holger@applied-asynchrony.com> wrote:
    >
    > On 2022-01-24 19:31, Greg Kroah-Hartman wrote:
    > > This is the start of the stable review cycle for the 5.15.17 release.
    >
    > Oh noes :(
    >
    > DESCEND bpf/resolve_btfids
    > MKDIR /tmp/linux-5.15.17/tools/bpf/resolve_btfids//libbpf
    > GEN /tmp/linux-5.15.17/tools/bpf/resolve_btfids/libbpf/bpf_helper_defs.h
    > MKDIR /tmp/linux-5.15.17/tools/bpf/resolve_btfids/libbpf/staticobjs/
    > CC /tmp/linux-5.15.17/tools/bpf/resolve_btfids/libbpf/staticobjs/libbpf.o
    > libbpf.c: In function 'bpf_object__elf_collect':
    > libbpf.c:3038:31: error: invalid type argument of '->' (have 'GElf_Shdr' {aka 'Elf64_Shdr'})
    > 3038 | if (sh->sh_type != SHT_PROGBITS)
    > | ^~
    > libbpf.c:3042:31: error: invalid type argument of '->' (have 'GElf_Shdr' {aka 'Elf64_Shdr'})
    > 3042 | if (sh->sh_type != SHT_PROGBITS)
    > | ^~
    > make[4]: *** [/tmp/linux-5.15.17/tools/build/Makefile.build:97: /tmp/linux-5.15.17/tools/bpf/resolve_btfids/libbpf/staticobjs/libbpf.o] Error 1
    > make[3]: *** [Makefile:158: /tmp/linux-5.15.17/tools/bpf/resolve_btfids/libbpf/staticobjs/libbpf-in.o] Error 2
    > make[2]: *** [Makefile:44: /tmp/linux-5.15.17/tools/bpf/resolve_btfids//libbpf/libbpf.a] Error 2
    > make[1]: *** [Makefile:72: bpf/resolve_btfids] Error 2
    > make: *** [Makefile:1371: tools/bpf/resolve_btfids] Error 2
    >
    > Reverting "libbpf-validate-that-.btf-and-.btf.ext-sections-cont.patcht" aka
    > this one:
    >
    > > Andrii Nakryiko <andrii@kernel.org>
    > > libbpf: Validate that .BTF and .BTF.ext sections contain data
    >
    > makes it build & run fine. I looked for followups but couldn't find anything that
    > stood out, maybe the BPF folks (cc'ed) know what's missing/wrong.
    >

    That small fix depends on much bigger refactoring in ad23b7238474
    ("libbpf: Use Elf64-specific types explicitly for dealing with ELF").
    I think this small fix can be dropped.

    That's sort of a general rule with libbpf-related fixes, they are
    usually not that critical to backport to stable, because most users
    use/build libbpf from its Github mirror, which is always taken from
    latest bpf-next. Libbpf is also not supposed to be used with untrusted
    inputs (i.e., BPF object files) as BPF programs are loaded into the
    kernel under root.


    > cheers
    > Holger

    \
     
     \ /
      Last update: 2022-01-25 04:39    [W:3.397 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site