BPF List
 help / color / mirror / Atom feed
* [PATCH bpf-next v9 0/7] libbpf: BPF program manual loading
@ 2026-10-29 22:33 Andrey Grodzovsky
  2026-10-29 22:33 ` [PATCH bpf-next v9 1/7] libbpf: Reject gen_loader set after PREPARE step Andrey Grodzovsky
                   ` (7 more replies)
  0 siblings, 8 replies; 14+ messages in thread
From: Andrey Grodzovsky @ 2026-10-29 22:33 UTC (permalink / raw)
  To: bpf, andrii, ast; +Cc: martin.kelly, slava.imameev

This series was originally posted in January 2025 [1] as a two-patch RFC
introducing a per-program tri-state load strategy (disabled/auto/manual)
to let large BPF applications load a subset of their programs lazily,
independent of the initial bpf_object load.

Motivation:

Security tools built on top of libbpf commonly ship as a single large
BPF object containing many programs, only a subset of which are needed
on any given system -- the rest are gated on optional features or on
kernel/runtime capabilities that vary across deployments. For this class
of application, per-program manual loading helps in two ways:

  - it shortens the initial load, since only the programs actually
    needed for the running configuration are loaded and attached up
    front instead of the whole object; and
  - it lets a single failing program be unloaded and possibly reloaded
    (or a feature toggled at runtime) without tearing down and reloading
    the entire bpf_object.

Both reduce the time window during which the tool is partially loaded or
inactive -- for a security tool specifically, that is also the time
window during which the system it protects is left vulnerable.

We have been running this with our internal fork of libbpf in production
for about a year. Depending on kernel and configuration support, around
250 of our programs are potentially loadable on any given system; with
manual loading, only around 90 of those are actually loaded by default,
growing to the full 250 only when every optional feature is enabled.
Cutting the default set of loaded programs from 250 down to 90 measurably
reduces load time (we observed ~60% reduction in our own measurements),
and since unload time scales with the number of loaded programs, it
correspondingly shortens unload time as well -- which matters, since
slow unload can delay system shutdown.

We believe this functionality would benefit other libbpf consumers with
similarly large, modular BPF applications.

Changes since v8 [2]:
  - New Patch 2: free func_info, line_info and subprogs in
    bpf_program__exit(), so bpf_program__unload() only closes the fd
    for any program (Alexei).
  - Patch 4: keep the reloc_desc of MANUAL programs when the bulk load frees
    relocation descriptors, so the verifier log of a later
    bpf_program__load() still gets the CO-RE relocation fixup (Alexei,
    Sashiko)
  - Patch 4: comment the force argument of bpf_object_post_load_cleanup()
    at the bpf_object__close() call (Andrii)
  - Patch 6: merge the load strategy transitions test into the manual load
    test as a subtest instead of a standalone load_type test, dropping
    the part of it that duplicated the manual load cycle (Sashiko)
  - Drop Assisted-by tags from commits, it was recently removed from documentation
    in mainline.
    
Development was assisted by LLM.

[1] https://lore.kernel.org/bpf/20250122215206.59859-1-slava.imameev@crowdstrike.com/
[2] https://lore.kernel.org/bpf/20261024014514.2959514-1-andrey.grodzovsky@crowdstrike.com/

Andrey Grodzovsky (4):
  libbpf: Reject gen_loader set after PREPARE step.
  libbpf: Free func_info, line_info and subprogs in bpf_program__exit()
  libbpf: Support declarative manual load via SEC("!...") prefix
  selftests/bpf: Convert veristat to BPF_PROG_LOAD_STRATEGY_MANUAL

Slava Imameev (3):
  libbpf: BPF program load strategy enum
  libbpf: BPF programs manual loading and attaching
  selftests/bpf: Cover BPF program load strategies and manual loading

 tools/lib/bpf/libbpf.c                        | 261 +++++++--
 tools/lib/bpf/libbpf.h                        |  84 +++
 tools/lib/bpf/libbpf.map                      |   4 +
 .../selftests/bpf/prog_tests/manual_load.c    | 507 ++++++++++++++++++
 .../selftests/bpf/prog_tests/signed_loader.c  |  32 ++
 .../bpf/prog_tests/test_struct_ops_arena.c    |  48 +-
 .../selftests/bpf/progs/test_manual_load.c    |  70 +++
 tools/testing/selftests/bpf/veristat.c        |  20 +-
 8 files changed, 968 insertions(+), 58 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/manual_load.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_manual_load.c

base-commit: d80373a8e70d3193151232c3062abbbe367ff5ad
-- 
2.34.1


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2026-10-30 21:29 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-29 22:33 [PATCH bpf-next v9 0/7] libbpf: BPF program manual loading Andrey Grodzovsky
2026-10-29 22:33 ` [PATCH bpf-next v9 1/7] libbpf: Reject gen_loader set after PREPARE step Andrey Grodzovsky
2026-10-29 22:33 ` [PATCH bpf-next v9 2/7] libbpf: Free func_info, line_info and subprogs in bpf_program__exit() Andrey Grodzovsky
2026-10-29 22:33 ` [PATCH bpf-next v9 3/7] libbpf: BPF program load strategy enum Andrey Grodzovsky
2026-10-29 22:33 ` [PATCH bpf-next v9 4/7] libbpf: BPF programs manual loading and attaching Andrey Grodzovsky
2026-10-29 22:54   ` sashiko-bot
2026-10-30 18:32   ` Andrii Nakryiko
2026-10-30 21:29     ` Andrey Grodzovsky
2026-10-29 22:33 ` [PATCH bpf-next v9 5/7] libbpf: Support declarative manual load via SEC("!...") prefix Andrey Grodzovsky
2026-10-29 22:33 ` [PATCH bpf-next v9 6/7] selftests/bpf: Cover BPF program load strategies and manual loading Andrey Grodzovsky
2026-10-29 22:33 ` [PATCH bpf-next v9 7/7] selftests/bpf: Convert veristat to BPF_PROG_LOAD_STRATEGY_MANUAL Andrey Grodzovsky
2026-10-29 22:45   ` sashiko-bot
2026-10-30 18:32   ` Andrii Nakryiko
2026-10-30 18:40 ` [PATCH bpf-next v9 0/7] libbpf: BPF program manual loading patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox