Re: [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2
From: Christophe Leroy <hidden>
Date: 2023-01-17 14:27:37
Also in:
bpf, linux-mips, linux-riscv, linux-s390, loongarch, netdev, sparclinux
Le 17/01/2023 à 15:18, Tonghao Zhang a écrit :
quoted
On Jan 17, 2023, at 7:36 PM, Christophe Leroy [off-list ref] wrote: Le 17/01/2023 à 08:30, Christophe Leroy a écrit :quoted
Le 17/01/2023 à 06:30, Tonghao Zhang a écrit :quoted
quoted
On Jan 9, 2023, at 4:15 PM, Christophe Leroy [off-list ref] wrote: Le 06/01/2023 à 16:37, Daniel Borkmann a écrit :quoted
On 1/5/23 6:53 PM, Christophe Leroy wrote:quoted
Le 05/01/2023 à 04:06, tong@infragraf.org a écrit :quoted
From: Tonghao Zhang <redacted> The x86_64 can't dump the valid insn in this way. A test BPF prog which include subprog: $ llvm-objdump -d subprog.o Disassembly of section .text: 0000000000000000 <subprog>: 0: 18 01 00 00 73 75 62 70 00 00 00 00 72 6f 67 00 r1 = 29114459903653235 ll 2: 7b 1a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r1 3: bf a1 00 00 00 00 00 00 r1 = r10 4: 07 01 00 00 f8 ff ff ff r1 += -8 5: b7 02 00 00 08 00 00 00 r2 = 8 6: 85 00 00 00 06 00 00 00 call 6 7: 95 00 00 00 00 00 00 00 exit Disassembly of section raw_tp/sys_enter: 0000000000000000 <entry>: 0: 85 10 00 00 ff ff ff ff call -1 1: b7 00 00 00 00 00 00 00 r0 = 0 2: 95 00 00 00 00 00 00 00 exit kernel print message: [ 580.775387] flen=8 proglen=51 pass=3 image=ffffffffa000c20c from=kprobe-load pid=1643 [ 580.777236] JIT code: 00000000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 580.779037] JIT code: 00000010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 580.780767] JIT code: 00000020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc [ 580.782568] JIT code: 00000030: cc cc cc $ bpf_jit_disasm 51 bytes emitted from JIT compiler (pass:3, flen:8) ffffffffa000c20c + <x>: 0: int3 1: int3 2: int3 3: int3 4: int3 5: int3 ... Until bpf_jit_binary_pack_finalize is invoked, we copy rw_header to header and then image/insn is valid. BTW, we can use the "bpftool prog dump" JITed instructions.NACK. Because the feature is buggy on x86_64, you remove it for all architectures ? On powerpc bpf_jit_enable == 2 works and is very usefull. Last time I tried to use bpftool on powerpc/32 it didn't work. I don't remember the details, I think it was an issue with endianess. Maybe it is fixed now, but it needs to be verified. So please, before removing a working and usefull feature, make sure there is an alternative available to it for all architectures in all configurations. Also, I don't think bpftool is usable to dump kernel BPF selftests. That's vital when a selftest fails if you want to have a chance to understand why it fails.If this is actively used by JIT developers and considered useful, I'd be ok to leave it for the time being. Overall goal is to reach feature parity among (at least major arch) JITs and not just have most functionality only available on x86-64 JIT. Could you however check what is not working with bpftool on powerpc/32? Perhaps it's not too much effort to just fix it, but details would be useful otherwise 'it didn't work' is too fuzzy.Sure I will try to test bpftool again in the coming days. Previous discussion about that subject is here: https://patchwork.kernel.org/project/linux-riscv/patch/20210415093250.3391257-1-Jianlin.Lv@arm.com/#24176847=Hi Christophe Any progress? We discuss to deprecate the bpf_jit_enable == 2 in 2021, but bpftool can not run on powerpc. Now can we fix this issue?Hi Tong, I have started to look at it but I don't have any fruitfull feedback yet.Hi Again, I tested again, the problem is still the same as one year ago: root@vgoip:~# ./bpftool prog libbpf: elf: endianness mismatch in pid_iter_bpf.It seem to be not right ehdr->e_ident[EI_DATA]. Do we can print the real value? /* * e_ident[EI_DATA] */ #define ELFDATANONE 0 #define ELFDATA2LSB 1 #define ELFDATA2MSB 2 #define ELFDATANUM 3 bpf_object__elf_init: obj->efile.ehdr = ehdr = elf64_getehdr(elf);quoted
libbpf: failed to initialize skeleton BPF object 'pid_iter_bpf': -4003 Error: failed to open PID iterator skeleton root@vgoip:~# uname -a Linux vgoip 6.2.0-rc3-02596-g1c2c9c13e256 #242 PREEMPT Tue Jan 17 09:36:08 CET 2023 ppc GNU/LinuxOn my pc, elf is little endian. # readelf -h tools/bpf/bpftool/pid_iter.bpf.o ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian # x86_64 Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Linux BPF Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 64832 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 13 Section header string table index: 1
Yes, must be something wrong with the build, I get same as you : $ LANG= readelf -h pid_iter.bpf.o ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Linux BPF Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 34704 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 13 Section header string table index: 1 Whereas I expect the same as bpftool I suppose, which is : $ LANG= readelf -h bpftool ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: PowerPC Version: 0x1 Entry point address: 0x100027d0 Start of program headers: 52 (bytes into file) Start of section headers: 1842896 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 9 Size of section headers: 40 (bytes) Number of section headers: 39 Section header string table index: 38 Thanks Christophe