Re: [PATCH bpf-next v3 3/4] libbpf: Request verifier warnings for object loads

sashiko-bot
2026-04-18T18:35:06Z

Sashiko AI review found 3 potential issue(s):
- [High] Valid BPF programs fail to load when a custom log buffer is too small to fit warnings.
- [High] Massive performance and memory regression for valid programs generating warnings.
- [Low] Empty debug logs are printed for every successful load without warnings.
--

commit ba31f1c82128deb94a4d629517c67a68ad69c567
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

libbpf: Request verifier warnings for object loads

On kernels supporting BPF_LOG_LEVEL_WARN, have libbpf request verifier
warnings for BPF object program loads by ORing in the warning bit. This
keeps the existing log_level=0 retry semantics for verbose logs, while
still surfacing verifier warnings for successful loads.

When libbpf owns the log buffer, use a small buffer for warning-only
loads and flush captured warnings through the print callback. Detect
support by probing for BPF_FEAT_VERIFIER_WARNINGS in enum bpf_features,
and document the updated kernel_log_level behavior.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 3a80a018fc7d5..c7b00c0976983 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -7936,7 +7940,9 @@ static int bpf_object_load_prog(struct bpf_object *obj, struct bpf_program *prog
> log_buf_size = obj->log_size;
> own_log_buf = false;
> } else {
> - log_buf_size = max((size_t)BPF_LOG_BUF_SIZE, log_buf_size * 2);
> + log_buf_size = max(log_level == 16 ? warn_log_buf_size :
> + (size_t)BPF_LOG_BUF_SIZE,
> + log_buf_size * 2);
> tmp = realloc(log_buf, log_buf_size);

If a valid program generates more than 4096 bytes (warn_log_buf_size) of
warnings, won't the kernel's bpf_vlog_finalize() detect the log truncation
and return -ENOSPC, causing bpf_prog_load() to fail?

[ ... ]

> ret = bpf_prog_load(prog->type, prog_name, license, insns, insns_cnt, &load_attr);
> if (ret >= 0) {
> - if (log_level && own_log_buf) {
> + if (log_level == 16 && load_attr.log_true_size && own_log_buf) {
> + pr_warn("prog '%s': -- BEGIN PROG LOAD WARNINGS --\n%s-- END PROG LOAD WARNINGS --\n",
> + prog->name, log_buf);
> + } else if (log_level && own_log_buf) {

If the program loads successfully and generates no warnings, load_attr.log_true_size
will be 0. Doesn't this skip the first check and fall through to the else-if,
causing libbpf to unconditionally print an empty debug log for every successful load?

> pr_debug("prog '%s': -- BEGIN PROG LOAD LOG --\n%s-- END PROG LOAD LOG --\n",
> prog->name, log_buf);
> }

[ ... ]

> @@ -7981,8 +7990,8 @@ static int bpf_object_load_prog(struct bpf_object *obj, struct bpf_program *prog
> goto out;
> }
>
> - if (log_level == 0) {
> - log_level = 1;
> + if (log_level == (supports_verifier_warnings ? 16 : 0)) {
> + log_level = 1 | (supports_verifier_warnings ? 16 : 0);
> goto retry_load;
> }

If the kernel returns -ENOSPC because the warnings did not fit in the buffer,
we hit this retry logic and bump log_level to 17 (BPF_LOG_LEVEL1 | BPF_LOG_LEVEL_WARN).

If the user provided a custom log buffer (own_log_buf == false), libbpf will not
resize it before retrying. Won't the second attempt also fail with -ENOSPC,
causing a valid program to fail to load simply because its warnings didn't fit
the custom buffer?

Additionally, if own_log_buf == true and we failed because the warnings exceeded
the initial 4096-byte buffer, retrying with log_level = 17 will allocate a 16MB
buffer and trigger a full instruction-by-instruction verification trace. Won't
this cause a massive CPU and memory regression just to load a valid program?

--
Sashiko AI review · https://sashiko.dev/#/patchset/20260418171701.610025-1-memxor@gmail.com?part=3