From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) (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 031CB311977 for ; Wed, 26 Nov 2025 19:02:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764183733; cv=none; b=Ip+OKz/7dY7T1ZPKBSDoXFbzAjPHQVC0GzAwIw7bx9CahWnabcm+plQQt3ww8jdAdgifOBpB3EHtbT2ItC/SFlorFy/wtLbR9ElFL07i+Uf3TNbpk6ZuYp9gWKZbil3LQM76pTXf1VPq9fe/moy4A0DJjtHPn1MBqdmAsEhtrFo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764183733; c=relaxed/simple; bh=PGb8QzCiz9c4xSY4LPkdirXHsPvgBNAHw9qgYtuKWIg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gYfjW9uK2H6aEmHiTod5OouEu/a8GutdiolB7bsWXE8j+YvVHGRlz5ZcGww0e02eWLG4aD3aW0hOfjUJhmbpmIdYpRKAT7L69H1BzyyxHcYWjhFp/o7GqpmQXDQTk55ITyxlG9ZZVacGxLTvW6W+sjmmaxe3NBh5S4QJxpxXCO8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=jWv7MUXT; arc=none smtp.client-ip=95.215.58.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="jWv7MUXT" Message-ID: <362b4519-522f-440b-a2ed-bd233166609b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1764183718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YF+vsyUPsLX+oIXuhWbF9px0T1obEdHnI8t1Kbok7xs=; b=jWv7MUXTuCuMm5O1dI2pDhkIp7Tos4/paH/uMgfCpFyy0ge38vXNgek8dsVN03YJ9sK9wu DzidIyBE0iGb5GOC9oZXsHrGbjJ+eJ5xD9VKxVosKouOiVVpKfQG9nnCu7vZntPSPhWeZR O5/qXNoXN68Vee2K6QC6hpus+iw3ujw= Date: Wed, 26 Nov 2025 11:01:24 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v1 0/4] resolve_btfids: Support for BTF modifications To: Alan Maguire , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt Cc: bpf@vger.kernel.org, dwarves@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, Donglin Peng References: <20251126012656.3546071-1-ihor.solodrai@linux.dev> <5bd0b578-e9ff-4958-b01c-fa3e9336eecb@oracle.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ihor Solodrai In-Reply-To: <5bd0b578-e9ff-4958-b01c-fa3e9336eecb@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 11/26/25 4:36 AM, Alan Maguire wrote: > On 26/11/2025 01:26, Ihor Solodrai wrote: >> This series changes resolve_btfids and kernel build scripts to enable >> BTF transformations in resolve_btfids. Main motivation for enhancing >> resolve_btfids is to reduce dependency of the kernel build on pahole >> capabilities [1] and enable BTF features and optimizations [2][3] >> particular to the kernel. >> >> Patches #1-#3 in the series are non-functional refactoring in >> resolve_btfids. The last patch (#4) makes significant changes in >> resolve_btfids and introduces scripts/gen-btf.sh. Implementation >> changes are described in detail in the patch description. >> >> One RFC item in this patchset is the --distilled_base [4] handling. >> Before this patchset .BTF.base was generated and added to target >> binary by pahole, based on these conditions [5]: >> * pahole version >=1.28 >> * the kernel module is out-of-tree (KBUILD_EXTMOD) >> >> Since BTF finalization is now done by resolve_btfids, it requires >> btf__distill_base() to happen there. However, in my opinion, it is >> unnecessary to add and pass through a --distilled_base flag for >> resolve_btfids. >> > hi Ihor, > > Can you say more about what constitutes BTF finalization and why BTF > distillation prior to finalization (i.e. in pahole) isn't workable? Is > it the concern that we eliminate types due to filtering, or is it a > problem with sorting/tracking type ids? Are there operations we > do/anticipate that make prior distillation infeasbile? Thanks! Hi Alan, That's a good question. AFAIU the distillation should be done on the final BTF, after all the transformations (sorting, adding/removing BTF types) have been applied. At least this way we can be sure that the distilled base is valid. We certainly want BTF generation process to be the same for modules and the kernel, which means that BTF modifications in resolve_btfids have to be applied to module BTF also. So the question is whether btf2btf will be safe to do *after* distillation, and that of course depends on the specifics. Let's say pahole generated BTF for a module and a distilled base. If later some types are removed from module BTF, or a new type is added (that might refer to a type absent in distilled base), is the btf/base pair still valid? My intuition is that it is more reliable to distill the final-final BTF, and so with resolve_btfids taking over kernel BTF finalization it makes sense to do it there. Otherwise we may be upfront limiting ourselves in how module BTF can be changed in resolve_btfids. What are the reasons to keep distillation in pahole? It's a simple libbpf API call after all. Anything I might be missing? > >> Logically, any split BTF referring to kernel BTF is not very useful >> without the .BTF.base, which is why the feature was developed in the >> first place. Therefore it makes sense to always emit .BTF.base for all >> modules, unconditionally. This is implemented in the series. >> >> However it might be argued that .BTF.base is redundant for in-tree >> modules: it takes space the module ELF and triggers unnecessary >> btf__relocate() call on load [6]. It can be avoided by special-casing >> in-tree module handling in resolve_btfids either with a flag or by >> checking env variables. The trade-off is slight performance impact vs >> code complexity. >> > > I would say avoid distillation for in-tree modules if possible, as it > imposes runtime costs in relocation/type renumbering on module load. For > large modules (amdgpu take a bow) that could be non-trivial time-wise. > IMO the build-time costs/complexities are worth paying to avoid a > runtime tax on module load. Acked. I still would like to avoid passing flags around if possible. Is it reasonable to simply check for KBUILD_EXTMOD env var from withing resolve_btfids? Any drawbacks to that? Thanks. > >> [1] https://lore.kernel.org/dwarves/ba1650aa-fafd-49a8-bea4-bdddee7c38c9@linux.dev/ >> [2] https://lore.kernel.org/bpf/20251029190113.3323406-1-ihor.solodrai@linux.dev/ >> [3] https://lore.kernel.org/bpf/20251119031531.1817099-1-dolinux.peng@gmail.com/ >> [4] https://docs.kernel.org/bpf/btf.html#btf-base-section >> [5] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/tree/scripts/Makefile.btf#n29 >> [6] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/tree/kernel/bpf/btf.c#n6358 >> >> Ihor Solodrai (4): >> resolve_btfids: rename object btf field to btf_path >> resolve_btfids: factor out load_btf() >> resolve_btfids: introduce enum btf_id_kind >> resolve_btfids: change in-place update with raw binary output >> >> MAINTAINERS | 1 + >> scripts/Makefile.modfinal | 5 +- >> scripts/gen-btf.sh | 166 ++++++++++++++++++++++ >> scripts/link-vmlinux.sh | 42 +----- >> tools/bpf/resolve_btfids/main.c | 234 +++++++++++++++++++++++--------- >> 5 files changed, 348 insertions(+), 100 deletions(-) >> create mode 100755 scripts/gen-btf.sh >> >