Message ID | cover.1706491398.git.dxu@dxuuu.xyz |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-42055-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp303990dyb; Sun, 28 Jan 2024 17:24:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IHKspml6ckIXsxIuTvnG4J6LBsH/tWX8uhlq69QP78ln762y6o35A3X3zMzV3CQK4ckk0hr X-Received: by 2002:aca:2807:0:b0:3bd:dffe:7863 with SMTP id 7-20020aca2807000000b003bddffe7863mr4750510oix.58.1706491495916; Sun, 28 Jan 2024 17:24:55 -0800 (PST) Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id i15-20020aa787cf000000b006ddb7493e31si4714796pfo.404.2024.01.28.17.24.55 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jan 2024 17:24:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-42055-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@dxuuu.xyz header.s=fm2 header.b="Sp/P9ZFJ"; dkim=neutral (body hash did not verify) header.i=@messagingengine.com header.s=fm3 header.b=toSTS5fI; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-42055-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-42055-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id A098E282AE5 for <ouuuleilei@gmail.com>; Mon, 29 Jan 2024 01:24:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 49A58EEDE; Mon, 29 Jan 2024 01:24:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=dxuuu.xyz header.i=@dxuuu.xyz header.b="Sp/P9ZFJ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="toSTS5fI" Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 056A0D515; Mon, 29 Jan 2024 01:24:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=64.147.123.24 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706491464; cv=none; b=k7nF5f0u5nzgQc4LyZsEGJ0r62sZaaPT6e04HS1OQEP0xoCS1OCgJhCCM43IkXVmWHNt+qDt5z0g4URljhVjn8dwM0kxgBEqzU1Yg8O4Lg1fqHBO7Nrk9FWwB865n09YrOaBZiYVvZyGZtowuwj/U/n/Bj1TnorL4M8UEAiVLg8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706491464; c=relaxed/simple; bh=kQEe3sxHRS25R01Huae1wLO1VdyUa7hma2vI+TmJQuw=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=exqo8w9XMcTruA7bYtaIu9paCGKyTt8AILpdfuy4KCx/c1TKaqn/3151u44By+F2Jc5rM+IQbQ7gU+HZHVDhAVhfaMep8Rq6YmN9KM0qi4BQ+fUHTKxBEOckf7uD7NoqtuA1KiEN6+STIyWhCBKebAsmhLArA8IUCA61Qv/uYKE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dxuuu.xyz; spf=pass smtp.mailfrom=dxuuu.xyz; dkim=pass (2048-bit key) header.d=dxuuu.xyz header.i=@dxuuu.xyz header.b=Sp/P9ZFJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=toSTS5fI; arc=none smtp.client-ip=64.147.123.24 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=dxuuu.xyz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=dxuuu.xyz Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9954E3200ABB; Sun, 28 Jan 2024 20:24:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 28 Jan 2024 20:24:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to; s=fm2; t=1706491459; x=1706577859; bh=UASoXhX4PTY3QDklhg97M HiJ1GxNYruI0l1hSTsM1IQ=; b=Sp/P9ZFJkQIEHfcvNH4pxlWQcJTVOu3NARJrb QU0vlJmpM4nohk3iDeQEo/Uuk1NtXdRe9TzUPuLVLZwihZ2nMpR1SaHdOFYdPeJr zyyOLJHWmQv7wFfiklp11U0lm+k97FGE2W734EFNtr2HA1l0VDW6mjxCvSRt+cv2 Jz2l6Sncb1dytEyLi2GEvXGQ8aodcH4vddVYUfcqlyPdggq74hiSUGoZkM9NARAL grjLqJgJe/RfIVPH+Fxq0yr0PsDuKjMfahjqvFerrDmJPT3klD1YJQ4f8hx5H2my hiIvvxRm3KeWyQfKVuh8g6GeiEUxoxvfTxyklE1gB/WGbzKRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version:reply-to:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1706491459; x=1706577859; bh=UASoXhX4PTY3QDklhg97MHiJ1GxN YruI0l1hSTsM1IQ=; b=toSTS5fIeqME+j6fCgQl7sXWi2TbaNbgcEYAv/FUpQCi ojINcUtIFRCemYQFFUCw9KMt6lbUje5JxS9ppMq3UONrtbV910ynaSb71OoD+HR9 MskHaANtEDpX/5ZHaX0tU+6v3twRjwEl6fh9aWg3iJaQzjt41KBNs7OnsV5nkZUf 9Gf8uMy5g2kYfJaAOtwMMELWFbjTIAF79KrHS0lZ5rR+jWV+YW/iswh8WhA3oYi3 iEncy2kWOFdpaGrtvFoMJ0nG9xynxVzhhwcsP7Sl9yD5qe/JLLH1f5gG1Q8jBSZK VLY7S7aDF71kp6q6/qfmcapQgHbU65dYB5oHy/DKQw== X-ME-Sender: <xms:Qv62ZdjsQSYWbTlKTLSEqMzzeUVWsCelA_UpwRQPxO1pbHXMb9VtDw> <xme:Qv62ZSAE8nNVyjnQSVjZrXsWge5dcgOFoP5891x2RYn4LJanvbYpqiM9jdLBQJ1P_ 62DAc7xuFK7DVJxvA> X-ME-Received: <xmr:Qv62ZdHZoFIBgCnLzmLD3S7ZxEXX2DyqstxMiOMW2vy6EYK23Jj0mlqAdYVy07CZeSgvbkqi47Kp8joEaorqp0d-f4OR9TxCKAtWAHu_Fqg1hA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedtfedgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdlfeehmdenucfjughrpefhvf fufffkofgggfestdekredtredttdenucfhrhhomhepffgrnhhivghlucgiuhcuoegugihu segugihuuhhurdighiiiqeenucggtffrrghtthgvrhhnpeffffegjeduheelgfdtudekie ejgfegheehjefgieejveevteeiveeukefgheekjeenucffohhmrghinhepghhithhhuhgs rdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epugiguhesugiguhhuuhdrgiihii X-ME-Proxy: <xmx:Qv62ZSTwvQHw03v-B2f1Bae6pN4fJB-3Qs8pCTG6pZi9wB0IlqrCtg> <xmx:Qv62ZaxbEzm0olNmw8XT6u5Hgp2K4DFcOrRD_Mo1YqOS2_wuDmHRhA> <xmx:Qv62ZY4sEd0MomoUDEp5-KW2l923PFpKcPYCM2P57eJmietEO2dsGA> <xmx:Q_62Zfhc89QQ1-UiKEW_sidKxkm0BIiyi8TNBF-Dz_bCocdzYVhFcg> Feedback-ID: i6a694271:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 28 Jan 2024 20:24:17 -0500 (EST) From: Daniel Xu <dxu@dxuuu.xyz> To: linux-trace-kernel@vger.kernel.org, coreteam@netfilter.org, bpf@vger.kernel.org, linux-input@vger.kernel.org, cgroups@vger.kernel.org, netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, fsverity@lists.linux.dev, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, netfilter-devel@vger.kernel.org, alexei.starovoitov@gmail.com, olsajiri@gmail.com, quentin@isovalent.com, alan.maguire@oracle.com, memxor@gmail.com Subject: [PATCH bpf-next v4 0/3] Annotate kfuncs in .BTF_ids section Date: Sun, 28 Jan 2024 18:24:05 -0700 Message-ID: <cover.1706491398.git.dxu@dxuuu.xyz> X-Mailer: git-send-email 2.42.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789386026479181563 X-GMAIL-MSGID: 1789386026479181563 |
Series |
Annotate kfuncs in .BTF_ids section
|
|
Message
Daniel Xu
Jan. 29, 2024, 1:24 a.m. UTC
=== Description === This is a bpf-treewide change that annotates all kfuncs as such inside BTF_ids. This annotation eventually allows us to automatically generate kfunc prototypes from bpftool. We store this metadata inside a yet-unused flags field inside struct btf_id_set8 (thanks Kumar!). pahole will be taught where to look. More details about the full chain of events are available in commit 3's description. The accompanying pahole and bpftool changes can be viewed here on these "frozen" branches [0][1]. [0]: https://github.com/danobi/pahole/tree/kfunc_btf-v3-mailed [1]: https://github.com/danobi/linux/tree/kfunc_bpftool-mailed === Changelog === Changes from v3: * Rebase to bpf-next and add missing annotation on new kfunc Changes from v2: * Only WARN() for vmlinux kfuncs Changes from v1: * Move WARN_ON() up a call level * Also return error when kfunc set is not properly tagged * Use BTF_KFUNCS_START/END instead of flags * Rename BTF_SET8_KFUNC to BTF_SET8_KFUNCS Daniel Xu (3): bpf: btf: Support flags for BTF_SET8 sets bpf: btf: Add BTF_KFUNCS_START/END macro pair bpf: treewide: Annotate BPF kfuncs in BTF Documentation/bpf/kfuncs.rst | 8 +++---- drivers/hid/bpf/hid_bpf_dispatch.c | 8 +++---- fs/verity/measure.c | 4 ++-- include/linux/btf_ids.h | 21 +++++++++++++++---- kernel/bpf/btf.c | 8 +++++++ kernel/bpf/cpumask.c | 4 ++-- kernel/bpf/helpers.c | 8 +++---- kernel/bpf/map_iter.c | 4 ++-- kernel/cgroup/rstat.c | 4 ++-- kernel/trace/bpf_trace.c | 8 +++---- net/bpf/test_run.c | 8 +++---- net/core/filter.c | 20 +++++++++--------- net/core/xdp.c | 4 ++-- net/ipv4/bpf_tcp_ca.c | 4 ++-- net/ipv4/fou_bpf.c | 4 ++-- net/ipv4/tcp_bbr.c | 4 ++-- net/ipv4/tcp_cubic.c | 4 ++-- net/ipv4/tcp_dctcp.c | 4 ++-- net/netfilter/nf_conntrack_bpf.c | 4 ++-- net/netfilter/nf_nat_bpf.c | 4 ++-- net/xfrm/xfrm_interface_bpf.c | 4 ++-- net/xfrm/xfrm_state_bpf.c | 4 ++-- .../selftests/bpf/bpf_testmod/bpf_testmod.c | 8 +++---- 23 files changed, 87 insertions(+), 66 deletions(-)
Comments
Hello: This series was applied to bpf/bpf-next.git (master) by Alexei Starovoitov <ast@kernel.org>: On Sun, 28 Jan 2024 18:24:05 -0700 you wrote: > === Description === > > This is a bpf-treewide change that annotates all kfuncs as such inside > .BTF_ids. This annotation eventually allows us to automatically generate > kfunc prototypes from bpftool. > > We store this metadata inside a yet-unused flags field inside struct > btf_id_set8 (thanks Kumar!). pahole will be taught where to look. > > [...] Here is the summary with links: - [bpf-next,v4,1/3] bpf: btf: Support flags for BTF_SET8 sets https://git.kernel.org/bpf/bpf-next/c/79b47344bbc5 - [bpf-next,v4,2/3] bpf: btf: Add BTF_KFUNCS_START/END macro pair https://git.kernel.org/bpf/bpf-next/c/2747e0ee57c2 - [bpf-next,v4,3/3] bpf: treewide: Annotate BPF kfuncs in BTF https://git.kernel.org/bpf/bpf-next/c/6e7769e6419f You are awesome, thank you!
On 2/3/24 19:45, Manu Bretelle wrote: > On Sat, Feb 03, 2024 at 03:40:24PM +0100, Jiri Olsa wrote: >> On Fri, Feb 02, 2024 at 03:09:05PM -0800, Manu Bretelle wrote: >>> On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote: >>>> === Description === >>>> >>>> This is a bpf-treewide change that annotates all kfuncs as such inside >>>> .BTF_ids. This annotation eventually allows us to automatically generate >>>> kfunc prototypes from bpftool. >>>> >>>> We store this metadata inside a yet-unused flags field inside struct >>>> btf_id_set8 (thanks Kumar!). pahole will be taught where to look. >>>> >>>> More details about the full chain of events are available in commit 3's >>>> description. >>>> >>>> The accompanying pahole and bpftool changes can be viewed >>>> here on these "frozen" branches [0][1]. >>>> >>>> [0]: https://github.com/danobi/pahole/tree/kfunc_btf-v3-mailed >>>> [1]: https://github.com/danobi/linux/tree/kfunc_bpftool-mailed >>> >>> >>> I hit a similar issue to [0] on master >>> 943b043aeecc ("selftests/bpf: Fix bench runner SIGSEGV") >>> when cross-compiling on x86_64 (LE) to s390x (BE). >>> I do have CONFIG_DEBUG_INFO_BTF enable and the issue would not trigger if >>> I disabled CONFIG_DEBUG_INFO_BTF (and with the fix mentioned in [0]). >>> >>> What seems to happen is that `tools/resolve_btfids` is ran in the context of the >>> host endianess and if I printk before the WARN_ON: >>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c >>> index ef380e546952..a9ed7a1a4936 100644 >>> --- a/kernel/bpf/btf.c >>> +++ b/kernel/bpf/btf.c >>> @@ -8128,6 +8128,7 @@ int register_btf_kfunc_id_set(enum bpf_prog_type prog_type, >>> * WARN() for initcall registrations that do not check errors. >>> */ >>> if (!(kset->set->flags & BTF_SET8_KFUNCS)) { >>> + printk("Flag 0x%08X, expected 0x%08X\n", kset->set->flags, BTF_SET8_KFUNCS); >>> WARN_ON(!kset->owner); >>> return -EINVAL; >>> } >>> >>> the boot logs would show: >>> Flag 0x01000000, expected 0x00000001 >>> >>> The issue did not happen prior to >>> 6f3189f38a3e ("bpf: treewide: Annotate BPF kfuncs in BTF") >>> has only 0 was written before. >>> >>> It seems [1] will be addressing cross-compilation, but it did not fix it as is >>> by just applying on top of master, so probably some of the changes will also need >>> to be ported to `tools/include/linux/btf_ids.h`? >> >> the fix in [1] is fixing flags in set8's pairs, but not the global flags >> >> it looks like Viktor's fix should now also swap that as well? like in the >> change below on top of Viktor's changes (untested) >> >> jirka >> >> >> --- >> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c >> index d01603ef6283..c44d57fec390 100644 >> --- a/tools/bpf/resolve_btfids/main.c >> +++ b/tools/bpf/resolve_btfids/main.c >> @@ -706,6 +706,8 @@ static int sets_patch(struct object *obj) >> * correctly translate everything. >> */ >> if (need_bswap) { >> + set8->flags = bswap_32(set8->flags); >> + >> for (i = 0; i < cnt; i++) { >> set8->pairs[i].flags = >> bswap_32(set8->pairs[i].flags); >> > > That should work. Here are a few tests I ran: > > $ md5sum /tmp/kbuild-s390x/vmlinux.* > eb658e51e089f3c5b2c8909a29dc9997 /tmp/kbuild-s390x/vmlinux.a > # plain vmlinux before running resolv_btfids (all 0s) > ea907cd46a1a73b8276b5f2a82af00ca /tmp/kbuild-s390x/vmlinux.before_resolv > # x86_64 resolv_btfids on master without Viktor's patch > 980a40c3a3ff563d1c2d1ebdd5071a23 /tmp/kbuild-s390x/vmlinux.resolv_native > # x86_64 resolv_btfids on master with Viktor's patch > b986d19e242719ebea41c578235da662 /tmp/kbuild-s390x/vmlinux.resolv_native_patch_viktor > # x86_64 resolv_btfids on master with Viktor's patch and your suggested patch > 4edd8752ff01129945bd442689b1927b /tmp/kbuild-s390x/vmlinux.resolv_native_patch_viktor_patched > # s390x resolv_btfids run with qemu-s390x-static > 4edd8752ff01129945bd442689b1927b /tmp/kbuild-s390x/vmlinux.resolv_s390x > > > and some hexdiff of those binaries: > > > # difference between master's native build and s390x build.... has byte swapping for set8 and others > diff -ruN <(xxd /tmp/kbuild-s390x/vmlinux.resolv_s390x) <(xxd /tmp/kbuild-s390x/vmlinux.resolv_native) > diff_s390x_native.diff > https://gist.github.com/chantra/c3d58637a08a6f7340953dc155bb18cc > > # difference betwee Viktor's version and s390x build.... squinting my eyes I only see the global set8 is missing > diff -ruN <(xxd /tmp/kbuild-s390x/vmlinux.resolv_s390x) <(xxd /tmp/kbuild-s390x/vmlinux.resolv_native_patch_viktor) > diff_s390x_native_viktor.diff > https://gist.github.com/chantra/61cfff02b456ae72d3c0161ce1897097 Thanks for the testing Manu! Jiri's suggested fix is now a part of [1]. Viktor [1] https://lore.kernel.org/bpf/cover.1707157553.git.vmalik@redhat.com/ > > Have a good weekend all! > > Manu >