On Fri, Jun 11, 2021 at 12:49 AM rainkin <rainkin1993@xxxxxxxxx> wrote: > > Hi, > > I try to run libbpf + CO-RE in old kernels (i.e., 4.19 here). > I follow the discussion in this thread > https://lore.kernel.org/bpf/CADmGQ+1euj7Uv9e8UyZMMXDiYAKqXe9=GSTBFNbbg1E0R-ejyg@xxxxxxxxxxxxxx/ > and successfully run a binary which compiled in kernel v5.8 in old kernel 4.19. > > Basically, I just compile the linux kernel 4.19 source code and run > pahole -J to generate a vmlinux containing .BTF sections. > Then I copy this vmlinux file in kernel v4.19 /boot/vmlinux-xxx where > libbpf will search vmlinux. You've probably also seen the discussion in that thread to make such use case better supported through libbpf API directly without you needing to put that vmlinux BTF in a special place. If you have such use case, please consider contributing necessary fixes. Thanks! > Finally, I run the eBPF compiled binary and it works perfectly (I can > get all the data I want). > > However, I find some error message shown by libbpf > e.g., > libbpf: Error loading BTF: Invalid argument(22) > libbpf: magic: 0xeb9f > ... > [10] Invalid btf_info:840000ad > libbpf: Error loading .BTF into kernel: -22. BTF is optional, ignoring. > > Although such errors do not prevent the binary running and the binary > works well, I still wonder what such errors mean. > Welcome any suggestions. > > The following is the complete logs: > > libbpf: loading object 'minimal_bpf' from buffer > libbpf: elf: section(2) raw_tp/sched_process_exec, size 280, link 0, > flags 6, type=1 > libbpf: sec 'raw_tp/sched_process_exec': found program > 'handle_sched_process_exec' at insn offset 0 (0 bytes), code size 35 > insns (280 bytes) > libbpf: elf: section(3) license, size 13, link 0, flags 3, type=1 > libbpf: license of minimal_bpf is Dual BSD/GPL > libbpf: elf: section(4) .rodata.str1.1, size 16, link 0, flags 32, type=1 > libbpf: elf: skipping unrecognized data section(4) .rodata.str1.1 > libbpf: elf: section(5) .BTF, size 23717, link 0, flags 0, type=1 > libbpf: elf: section(6) .BTF.ext, size 364, link 0, flags 0, type=1 > libbpf: elf: section(7) .symtab, size 96, link 11, flags 0, type=2 > libbpf: looking for externs among 4 symbols... > libbpf: collected 0 externs total > libbpf: loading kernel BTF '/boot/vmlinux-4.19.0-041900-generic': 0 > libbpf: Error loading BTF: Invalid argument(22) > libbpf: magic: 0xeb9f > version: 1 > flags: 0x0 > hdr_len: 24 > type_off: 0 > type_len: 14212 > str_off: 14212 > str_len: 9481 > btf_total_size: 23717 > [1] PTR (anon) type_id=2 > [2] STRUCT bpf_raw_tracepoint_args size=0 vlen=1 > args type_id=5 bits_offset=0 > [3] TYPEDEF __u64 type_id=4 > [4] INT long long unsigned int size=8 bits_offset=0 nr_bits=64 encoding=(none) > [5] ARRAY (anon) type_id=3 index_type_id=6 nr_elems=0 > [6] INT __ARRAY_SIZE_TYPE__ size=4 bits_offset=0 nr_bits=32 encoding=(none) > [7] ENUM (anon) size=4 vlen=1 > ctx val=1 > [8] INT int size=4 bits_offset=0 nr_bits=32 encoding=SIGNED > [9] TYPEDEF handle_sched_process_exec type_id=7 > [10] Invalid btf_info:840000ad > libbpf: Error loading .BTF into kernel: -22. BTF is optional, ignoring. it's a STRUCT with kflag set to 1, which means that it has bitfields with encoded bit offset and bit size in offset field. libbpf doesn't detect and sanitize such cases. But this error is just a warning and it doesn't influence correctness, so you can ignore that. But if you'd like to avoid this, take a look at what would it take to sanitize such cases. If it's not too gross and complicated, we can teach libbpf to do it automatically. [...]
