linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Tonghao Zhang <tong@infragraf.org>,
	Daniel Borkmann <daniel@iogearbox.net>
Cc: KP Singh <kpsingh@kernel.org>, Song Liu <song@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hou Tao <houtao1@huawei.com>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	"naveen.n.rao@linux.ibm.com" <naveen.n.rao@linux.ibm.com>,
	Yonghong Song <yhs@fb.com>,
	"linux-arm-kernel@lists.infradead.or"
	<linux-arm-kernel@lists.infradead.or>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Alexei Starovoitov <ast@kernel.org>,
	"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
	Hao Luo <haoluo@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	Jiri Olsa <jolsa@kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>
Subject: Re: [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2
Date: Tue, 17 Jan 2023 07:30:10 +0000	[thread overview]
Message-ID: <0b46b813-05f2-5083-9f2e-82d72970dae2@csgroup.eu> (raw)
In-Reply-To: <147A796D-12C0-482F-B48A-16E67120622B@infragraf.org>



Le 17/01/2023 à 06:30, Tonghao Zhang a écrit :
> 
> 
>> On Jan 9, 2023, at 4:15 PM, Christophe Leroy <christophe.leroy@csgroup.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@infragraf.org a écrit :
>>>>> From: Tonghao Zhang <tong@infragraf.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?

Hi Tong,

I have started to look at it but I don't have any fruitfull feedback yet.

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

>>
>>>
>>> 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
> 

  reply	other threads:[~2023-01-17  7:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05  3:06 [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2 tong
2023-01-05  9:36 ` Björn Töpel
2023-01-05 17:53 ` Christophe Leroy
2023-01-06 12:05   ` Tonghao Zhang
2023-01-06 12:23   ` Tonghao Zhang
2023-01-06 13:22   ` Tonghao Zhang
2023-01-06 15:37   ` Daniel Borkmann
2023-01-09  8:15     ` Christophe Leroy
2023-01-17  5:30       ` Tonghao Zhang
2023-01-17  7:30         ` Christophe Leroy [this message]
2023-01-17 11:36           ` Christophe Leroy
2023-01-17 14:18             ` Tonghao Zhang
2023-01-17 14:25               ` Christophe Leroy
2023-01-17 14:41                 ` Quentin Monnet
2023-01-17 14:55                   ` Christophe Leroy
2023-01-17 15:42                     ` Quentin Monnet
2023-01-23  7:57                       ` Christophe Leroy
2023-01-23 10:57                         ` Quentin Monnet
2023-01-17 14:22           ` Tonghao Zhang
2023-01-17 15:59             ` Daniel Borkmann
2023-01-18  2:13               ` Tonghao Zhang
2023-01-18  2:21                 ` Alexei Starovoitov
2023-01-18  7:35                   ` Christophe Leroy
2023-01-18 17:42                     ` Alexei Starovoitov
2023-01-23  8:00                       ` Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0b46b813-05f2-5083-9f2e-82d72970dae2@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=houtao1@huawei.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.or \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=loongarch@lists.linux.dev \
    --cc=martin.lau@linux.dev \
    --cc=naveen.n.rao@linux.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=tong@infragraf.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).