[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <be132117-f267-5817-136d-e1aeb8409c2a@csgroup.eu>
Date: Fri, 23 Apr 2021 09:19:06 +0200
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Quentin Monnet <quentin@...valent.com>,
Ian Rogers <irogers@...gle.com>,
Song Liu <songliubraving@...com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Zi Shen Lim <zlim.lnx@...il.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Alexei Starovoitov <ast@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>,
Paul Mackerras <paulus@...ba.org>,
Sandipan Das <sandipan@...ux.ibm.com>,
"H. Peter Anvin" <hpa@...or.com>, sparclinux@...r.kernel.org,
Shubham Bansal <illusionist.neo@...il.com>,
Mahesh Bandewar <maheshb@...gle.com>,
Will Deacon <will@...nel.org>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
linux-s390 <linux-s390@...r.kernel.org>,
Ilya Leoshkevich <iii@...ux.ibm.com>, paulburton@...nel.org,
Jonathan Corbet <corbet@....net>,
Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
Masahiro Yamada <masahiroy@...nel.org>,
X86 ML <x86@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Russell King <linux@...linux.org.uk>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Christian Borntraeger <borntraeger@...ibm.com>,
Ingo Molnar <mingo@...hat.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Catalin Marinas <catalin.marinas@....com>,
"Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>,
Jakub Kicinski <kuba@...nel.org>,
Tobias Klauser <tklauser@...tanz.ch>,
linux-mips@...r.kernel.org, grantseltzer@...il.com,
Xi Wang <xi.wang@...il.com>, Albert Ou <aou@...s.berkeley.edu>,
Kees Cook <keescook@...omium.org>,
Vasily Gorbik <gor@...ux.ibm.com>,
Luke Nelson <luke.r.nels@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Heiko Carstens <hca@...ux.ibm.com>,
ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
KP Singh <kpsingh@...nel.org>, iecedge@...il.com,
Simon Horman <horms@...ge.net.au>,
Borislav Petkov <bp@...en8.de>,
Alexander Viro <viro@...iv.linux.org.uk>,
Yonghong Song <yhs@...com>,
Thomas Gleixner <tglx@...utronix.de>,
Dmitry Vyukov <dvyukov@...gle.com>, tsbogend@...ha.franken.de,
Daniel Borkmann <daniel@...earbox.net>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Network Development <netdev@...r.kernel.org>,
David Ahern <dsahern@...nel.org>,
Wang YanQing <udknight@...il.com>,
Martin KaFai Lau <kafai@...com>,
Björn Töpel <bjorn@...nel.org>,
Palmer Dabbelt <palmer@...belt.com>, bpf <bpf@...r.kernel.org>,
Jianlin Lv <Jianlin.Lv@....com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH bpf-next 1/2] bpf: Remove bpf_jit_enable=2 debugging mode
Le 20/04/2021 à 05:28, Alexei Starovoitov a écrit :
> On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
> <christophe.leroy@...roup.eu> wrote:
>>
>>
>>
>> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :
>>> On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet <quentin@...valent.com> wrote:
>>>>
>>>> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann <daniel@...earbox.net>
>>>>> On 4/15/21 11:32 AM, Jianlin Lv wrote:
>>>>>> For debugging JITs, dumping the JITed image to kernel log is discouraged,
>>>>>> "bpftool prog dump jited" is much better way to examine JITed dumps.
>>>>>> This patch get rid of the code related to bpf_jit_enable=2 mode and
>>>>>> update the proc handler of bpf_jit_enable, also added auxiliary
>>>>>> information to explain how to use bpf_jit_disasm tool after this change.
>>>>>>
>>>>>> Signed-off-by: Jianlin Lv <Jianlin.Lv@....com>
>>>>
>>>> Hello,
>>>>
>>>> For what it's worth, I have already seen people dump the JIT image in
>>>> kernel logs in Qemu VMs running with just a busybox, not for kernel
>>>> development, but in a context where buiding/using bpftool was not
>>>> possible.
>>>
>>> If building/using bpftool is not possible then majority of selftests won't
>>> be exercised. I don't think such environment is suitable for any kind
>>> of bpf development. Much so for JIT debugging.
>>> While bpf_jit_enable=2 is nothing but the debugging tool for JIT developers.
>>> I'd rather nuke that code instead of carrying it from kernel to kernel.
>>>
>>
>> When I implemented JIT for PPC32, it was extremely helpfull.
>>
>> As far as I understand, for the time being bpftool is not usable in my environment because it
>> doesn't support cross compilation when the target's endianess differs from the building host
>> endianess, see discussion at
>> https://lore.kernel.org/bpf/21e66a09-514f-f426-b9e2-13baab0b938b@csgroup.eu/
>>
>> That's right that selftests can't be exercised because they don't build.
>>
>> The question might be candid as I didn't investigate much about the replacement of "bpf_jit_enable=2
>> debugging mode" by bpftool, how do we use bpftool exactly for that ? Especially when using the BPF
>> test module ?
>
> the kernel developers can add any amount of printk and dumps to debug
> their code,
> but such debugging aid should not be part of the production kernel.
> That sysctl was two things at once: debugging tool for kernel devs and
> introspection for users.
> bpftool jit dump solves the 2nd part. It provides JIT introspection to users.
> Debugging of the kernel can be done with any amount of auxiliary code
> including calling print_hex_dump() during jiting.
>
I finally managed to cross compile bpftool with libbpf, libopcodes, readline, ncurses, libcap, libz
and all needed stuff. Was not easy but I made it.
Now, how do I use it ?
Let say I want to dump the jitted code generated from a call to 'tcpdump'. How do I do that with
'bpftool prog dump jited' ?
I thought by calling this line I would then get programs dumped in a way or another just like when
setting 'bpf_jit_enable=2', but calling that line just provides me some bpftool help text.
By the way, I would be nice to have a kernel OPTION that selects all OPTIONS required for building
bpftool. Because you discover them one by one at every build failure. I had to had CONFIG_IPV6,
CONFIG_DEBUG_BTF, CONFIG_CGROUPS, ... If there could be an option like "Build a 'bpftool' ready
kernel" that selected all those, it would be great.
Christophe
Powered by blists - more mailing lists