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

[sashiko-bot@kernel.org]

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