From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFEA2C43461 for ; Fri, 23 Apr 2021 07:19:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A5D9561450 for ; Fri, 23 Apr 2021 07:19:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230131AbhDWHTt (ORCPT ); Fri, 23 Apr 2021 03:19:49 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:18001 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229935AbhDWHTs (ORCPT ); Fri, 23 Apr 2021 03:19:48 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4FRQdS46lvz9tynk; Fri, 23 Apr 2021 09:19:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id 0oQPQKgd4ski; Fri, 23 Apr 2021 09:19:08 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4FRQdS3HSvz9tynf; Fri, 23 Apr 2021 09:19:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id C25808B798; Fri, 23 Apr 2021 09:19:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QeOANgzeLlXn; Fri, 23 Apr 2021 09:19:09 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id D2C2E8B765; Fri, 23 Apr 2021 09:19:06 +0200 (CEST) Subject: Re: [PATCH bpf-next 1/2] bpf: Remove bpf_jit_enable=2 debugging mode To: Alexei Starovoitov Cc: Quentin Monnet , Ian Rogers , Song Liu , "open list:DOCUMENTATION" , Zi Shen Lim , Paul Walmsley , Alexei Starovoitov , Andrii Nakryiko , Paul Mackerras , Sandipan Das , "H. Peter Anvin" , sparclinux@vger.kernel.org, Shubham Bansal , Mahesh Bandewar , Will Deacon , Nicolas Dichtel , linux-s390 , Ilya Leoshkevich , paulburton@kernel.org, Jonathan Corbet , Mauro Carvalho Chehab , Masahiro Yamada , X86 ML , John Fastabend , Russell King , linux-riscv , Christian Borntraeger , Ingo Molnar , linux-arm-kernel , Catalin Marinas , "Naveen N . Rao" , Jakub Kicinski , Tobias Klauser , linux-mips@vger.kernel.org, grantseltzer@gmail.com, Xi Wang , Albert Ou , Kees Cook , Vasily Gorbik , Luke Nelson , LKML , Heiko Carstens , ppc-dev , KP Singh , iecedge@gmail.com, Simon Horman , Borislav Petkov , Alexander Viro , Yonghong Song , Thomas Gleixner , Dmitry Vyukov , tsbogend@alpha.franken.de, Daniel Borkmann , Hideaki YOSHIFUJI , Network Development , David Ahern , Wang YanQing , Martin KaFai Lau , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Palmer Dabbelt , bpf , Jianlin Lv , "David S. Miller" References: <20210415093250.3391257-1-Jianlin.Lv@arm.com> <9c4a78d2-f73c-832a-e6e2-4b4daa729e07@iogearbox.net> <0dea05ba-9467-0d84-4515-b8766f60318e@csgroup.eu> From: Christophe Leroy Message-ID: Date: Fri, 23 Apr 2021 09:19:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Le 20/04/2021 à 05:28, Alexei Starovoitov a écrit : > On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy > wrote: >> >> >> >> Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit : >>> On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet wrote: >>>> >>>> 2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann >>>>> 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 >>>> >>>> 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