BPF List
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: ast@kernel.org, andrii@kernel.org, eddyz87@gmail.com, jolsa@kernel.org
Cc: daniel@iogearbox.net, ihor.solodrai@linux.dev,
	yonghong.song@linux.dev, song@kernel.org, qmo@kernel.org,
	martin.lau@linux.dev, memxor@gmail.com, emil@etsalapatis.com,
	bpf@vger.kernel.org, nsc@kernel.org, puranjay@kernel.org,
	yatsenko@meta.com, Alan Maguire <alan.maguire@oracle.com>
Subject: [PATCH v3 bpf-next 00/11] Support inline functions in BTF
Date: Wed, 16 Sep 2026 08:41:07 +0100	[thread overview]
Message-ID: <20260916074118.1007116-1-alan.maguire@oracle.com> (raw)

This series adds support to facilitate tracing of inline function
sites using BPF Type Format (BTF) information. An excellent overview
of the problem and proposed solution presented at LSF/MM/BPF is
available at [1].

The aim is to produce a compact representation providing sufficient
information to a tracer wishing to instrument an inline site via a
kprobe.  The challenge to solve is compact representation - my
local bpf-next builds show nearly 600,000 inline sites for approximately
100,000 functions.  Any BTF representation should utilize deduplication
where possible to minimize overheads.

The approach used here is to encode a series of inline sites in
a BTF DATASEC-like LOCSEC named for the associated section (like
"inline.text", where each entry consists of a

<function type id, location prototype id, offset from base address>

triple. The function type id is the BTF_KIND_FUNC that was inlined,
the location prototype is a BTF_KIND_LOC_PROTO which tells us
for each function parameter how it is represented at the site.
It is a collection of either type id 0 (parameter not available)
or BTF_KIND_LOC_PARAM ids, the latter encoding a register number,
a dereference, a constant etc.  Finally the offset is relative to
the base address, so in the case of the kernel this allows for
kASLR, and modules addresses are relative to module base address.

Full location parameter information is available for ~78% of
inlined functions; in other words all function parameters are
expressed via BTF_KIND_LOC_PARAM and can be retrieved.  Those
remaining have more complex multi-expression encoding or are
not available at all.

This series focuses on the underlying libbpf/kernel/bpftool support
for handling location data; with it in place pahole can utilize
the provided interfaces to generate inline data in combination with
general BTF data; it will then be separated out via resolve_btfids
into non-inline and inline information.

Support in pahole for generation of inline info using the libbpf
interfaces in this series is available in [2].

Patch 1 consists of the UAPI changes and associated basic support
for KIND_LOC[SEC|PARAM|PROTO].

Patch 2 adds associated libbpf support, covering dedup, field
iteration and distillation.

Patches 3-6 test various aspects of these features.

Patches 7-9 update bpftool to handle multi-split BTF (where
we potentially have module inline info sitting atop module
BTF info which in turn has vmlinux BTF as its base), and add
support for displaying location info in raw BTF dump.
Patch 10 tests bpftool raw dump of locations.

Finally patch 11 documents the location kinds.

Changes since v2 [3]:

- Split out location representation/handling (this series) from
  additions to kbuild machinery to add inline info.  This series
  provides the needed libbpf interfaces to pahole for inline location
  generation. A follow-up series will add libbpf permute support
  for splitting inline from non-inline info such that resolve_btfids
  can consume it, kbuild support for pahole inline flags and sysfs
  exposure of inline BTF.
- Updated location parameter API name, function to use flex array
  for parameter values (Eduard, patches 1, 2)
- Fixed dedup issues (Eduard, patch 2)
- Improved dedup/distill tests to cover more complex cases
  (patches 5, 6)
- Updated bpftool dump output to be more expressive for location
  parameters, prototypes and location sections (Alexei, patch 9).

Changes since RFC [4]:

- Support for distilled base BTF
- Support for BTF_INLINE=m on-demand loading
- Reworked inline support to handle new resolve_btfids model
- .BTF.inline sections host FUNCs/FUNC_PROTOs/strings that are
  needed for inline info only, avoiding polluting standard
  vmlinux/module BTFs

[1] https://lwn.net/Articles/1083985/
[2] https://lore.kernel.org/dwarves/20260902113829.1285407-1-alan.maguire@oracle.com/
[3] https://lore.kernel.org/bpf/20260901165757.801449-1-alan.maguire@oracle.com/
[4] https://lore.kernel.org/bpf/20251008173512.731801-1-alan.maguire@oracle.com/


Alan Maguire (11):
  btf: Extend UAPI to support BTF location (inline site) info
  libbpf: Add support for BTF kinds LOC[_PARAM|_PROTO|SEC]
  selftests/bpf: Test helper support for BTF_KIND_LOC[_PARAM|_PROTO|SEC]
  selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to field iter tests
  selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to dedup split tests
  selftests/bpf: BTF distill tests to ensure LOC[_PARAM|_PROTO] add to
    split BTF
  bpftool: Handle multi-split BTF by supporting multiple base BTFs
  bpftool: Document support for multi-split BTF
  bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC
  selftests/bpf: Test bpftool dump of BTF location info
  Documentation/bpf: Describe new location-related BTF kinds

 Documentation/bpf/btf.rst                     |  80 +++-
 include/linux/btf.h                           |  22 +-
 include/uapi/linux/btf.h                      |  65 ++-
 kernel/bpf/btf.c                              | 304 +++++++++++++-
 .../bpf/bpftool/Documentation/bpftool-btf.rst |   7 +-
 tools/bpf/bpftool/btf.c                       | 171 +++++++-
 tools/bpf/bpftool/main.c                      |  22 +-
 tools/include/uapi/linux/btf.h                |  65 ++-
 tools/lib/bpf/btf.c                           | 373 +++++++++++++++++-
 tools/lib/bpf/btf.h                           |  50 +++
 tools/lib/bpf/btf_dump.c                      |   9 +
 tools/lib/bpf/btf_iter.c                      |  18 +
 tools/lib/bpf/libbpf.map                      |   6 +
 tools/lib/bpf/libbpf_internal.h               |   2 +-
 tools/testing/selftests/bpf/btf_helpers.c     |  36 +-
 .../bpf/prog_tests/bpftool_btf_dump.c         |  84 ++++
 .../bpf/prog_tests/btf_dedup_split.c          | 116 ++++++
 .../selftests/bpf/prog_tests/btf_distill.c    | 101 +++++
 .../selftests/bpf/prog_tests/btf_field_iter.c |  31 +-
 tools/testing/selftests/bpf/test_btf.h        |  16 +
 20 files changed, 1555 insertions(+), 23 deletions(-)

-- 
2.43.5


             reply	other threads:[~2026-09-16  7:41 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  7:41 Alan Maguire [this message]
2026-09-16  7:41 ` [PATCH v3 bpf-next 01/11] btf: Extend UAPI to support BTF location (inline site) info Alan Maguire
2026-09-16  9:03   ` bot+bpf-ci
2026-09-16  7:41 ` [PATCH v3 bpf-next 02/11] libbpf: Add support for BTF kinds LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-16  7:55   ` sashiko-bot
2026-09-16  9:03   ` bot+bpf-ci
2026-09-16  7:41 ` [PATCH v3 bpf-next 03/11] selftests/bpf: Test helper support for BTF_KIND_LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-16  8:44   ` bot+bpf-ci
2026-09-18 18:34   ` Eduard Zingerman
2026-09-16  7:41 ` [PATCH v3 bpf-next 04/11] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to field iter tests Alan Maguire
2026-09-18 18:43   ` Eduard Zingerman
2026-09-16  7:41 ` [PATCH v3 bpf-next 05/11] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to dedup split tests Alan Maguire
2026-09-18 18:46   ` Eduard Zingerman
2026-09-16  7:41 ` [PATCH v3 bpf-next 06/11] selftests/bpf: BTF distill tests to ensure LOC[_PARAM|_PROTO] add to split BTF Alan Maguire
2026-09-18 19:59   ` Eduard Zingerman
2026-09-21 18:36     ` Alan Maguire
2026-09-16  7:41 ` [PATCH v3 bpf-next 07/11] bpftool: Handle multi-split BTF by supporting multiple base BTFs Alan Maguire
2026-09-16  7:54   ` sashiko-bot
2026-09-16  9:03   ` bot+bpf-ci
2026-09-16  7:41 ` [PATCH v3 bpf-next 08/11] bpftool: Document support for multi-split BTF Alan Maguire
2026-09-16  7:41 ` [PATCH v3 bpf-next 09/11] bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC Alan Maguire
2026-09-16  7:55   ` sashiko-bot
2026-09-16  9:03   ` bot+bpf-ci
2026-09-16 22:07   ` Jiri Olsa
2026-09-17  8:27     ` Alan Maguire
2026-09-17 22:00       ` Jiri Olsa
2026-09-18  9:19         ` Alan Maguire
2026-09-18 13:01           ` Jiri Olsa
2026-09-17 16:06   ` Quentin Monnet
2026-09-17 17:32     ` Alan Maguire
2026-09-18  7:29     ` Alan Maguire
2026-09-18 20:51   ` Eduard Zingerman
2026-09-21 18:47     ` Alan Maguire
2026-09-21 21:46       ` Eduard Zingerman
2026-09-22 11:59         ` Quentin Monnet
2026-09-23  8:47           ` Alan Maguire
2026-09-16  7:41 ` [PATCH v3 bpf-next 10/11] selftests/bpf: Test bpftool dump of BTF location info Alan Maguire
2026-09-16  7:56   ` sashiko-bot
2026-09-16  9:03   ` bot+bpf-ci
2026-09-16  7:41 ` [PATCH v3 bpf-next 11/11] Documentation/bpf: Describe new location-related BTF kinds Alan Maguire
2026-09-16  8:01   ` sashiko-bot
2026-09-16  9:03   ` bot+bpf-ci

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=20260916074118.1007116-1-alan.maguire@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=jolsa@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=nsc@kernel.org \
    --cc=puranjay@kernel.org \
    --cc=qmo@kernel.org \
    --cc=song@kernel.org \
    --cc=yatsenko@meta.com \
    --cc=yonghong.song@linux.dev \
    /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