Date:   Tue, 17 Jan 2023 13:30:49 +0800
From:   Tonghao Zhang <tong@...ragraf.org>
To:     Christophe Leroy <christophe.leroy@...roup.eu>,
        Daniel Borkmann <daniel@...earbox.net>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.or" 
        <linux-arm-kernel@...ts.infradead.or>,
        "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
        Hao Luo <haoluo@...gle.com>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Song Liu <song@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jiri Olsa <jolsa@...nel.org>, Hou Tao <houtao1@...wei.com>,
        KP Singh <kpsingh@...nel.org>, Yonghong Song <yhs@...com>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        "naveen.n.rao@...ux.ibm.com" <naveen.n.rao@...ux.ibm.com>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>
Subject: Re: [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2



> On Jan 9, 2023, at 4:15 PM, Christophe Leroy <christophe.leroy@...roup.eu> 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@...ragraf.org a écrit :
>>>> From: Tonghao Zhang <tong@...ragraf.org>
>>>> 
>>>> 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? 
> 
>> 
>> Also, with regards to the last statement that bpftool is not usable to
>> dump kernel BPF selftests. Could you elaborate some more? I haven't used
>> bpf_jit_enable == 2 in a long time and for debugging always relied on
>> bpftool to dump xlated insns or JIT. Or do you mean by BPF selftests
>> the test_bpf.ko module? Given it has a big batch with kernel-only tests,
>> there I can see it's probably still useful.
> 
> Yes I mean test_bpf.ko
> 
> I used it as the test basis when I implemented eBPF for powerpc/32. And 
> not so long ago it helped decover and fix a bug, see 
> https://github.com/torvalds/linux/commit/89d21e259a94f7d5582ec675aa445f5a79f347e4
> 
>> 
>> Cheers,
>> Daniel

Powered by blists - more mailing lists