Re: [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2

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

 




> On Jan 17, 2023, at 7:36 PM, Christophe Leroy <christophe.leroy@xxxxxxxxxx> wrote:
> 
> 
> 
> Le 17/01/2023 à 08:30, Christophe Leroy a écrit :
>> 
>> 
>> Le 17/01/2023 à 06:30, Tonghao Zhang a écrit :
>>> 
>>> 
>>>> On Jan 9, 2023, at 4:15 PM, Christophe Leroy 
>>>> <christophe.leroy@xxxxxxxxxx> wrote:
>>>> 
>>>> 
>>>> 
>>>> Le 06/01/2023 à 16:37, Daniel Borkmann a écrit :
>>>>> On 1/5/23 6:53 PM, Christophe Leroy wrote:
>>>>>> Le 05/01/2023 à 04:06, tong@xxxxxxxxxxxxx a écrit :
>>>>>>> From: Tonghao Zhang <tong@xxxxxxxxxxxxx>
>>>>>>> 
>>>>>>> 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@xxxxxxx/#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);

> 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/Linux
On 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

> 
>> 
>> In the meantime, were you able to confirm that bpftool can also be used 
>> to dump jitted tests from test_bpf.ko module on x86_64 ? In that can you 
>> tell me how to proceed ?
>> 
>> Thanks
>> Christophe
>> 
> 
> 
> Christophe




[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux