On Mon, Jan 24, 2022 at 02:09:13PM -0800, Andrii Nakryiko wrote:
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.
Ok, thanks, I'll drop this from all queues now.
greg k-h