Re: [PATCH bpf-next 4/4] bpf: Account scratch buffer in bpf_prog_calc_tag

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Missing memcg accounting for the temporary JIT scratch buffer `rw_header`.
--

--- Patch [4]: [PATCH bpf-next 4/4] bpf: Account scratch buffer in bpf_prog_calc_tag ---
commit 57c46cbb1e055c7c0a73414dd57ed04bc1cb8b73
Author: Daniel Borkmann <daniel@iogearbox.net>

bpf: Account scratch buffer in bpf_prog_calc_tag

This commit updates bpf_prog_calc_tag() to use GFP_KERNEL_ACCOUNT for its
vmalloc scratch buffer. This ensures the temporary memory, which scales with
the program size, is properly charged to the loader's memory cgroup.

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -305,7 +305,7 @@ int bpf_prog_calc_tag(struct bpf_prog *fp)
>  	bool was_ld_map;
>  	u32 i;
>  
> -	dst = vmalloc(size);
> +	dst = __vmalloc(size, GFP_KERNEL_ACCOUNT);

[Severity: Medium]
This is a pre-existing issue, but since this patch correctly applies memcg
accounting to load-time scratch memory, should we also account the
temporary JIT scratch buffer?

Looking at bpf_jit_binary_pack_alloc() in the same file, rw_header scales
with the program size but uses GFP_KERNEL instead of GFP_KERNEL_ACCOUNT:

kernel/bpf/core.c:bpf_jit_binary_pack_alloc() {
    ...
    *rw_header = kvmalloc(size, GFP_KERNEL);
    ...
}

Does this missing accounting allow a process to bypass its memcg limits by
triggering concurrent JIT compilations?

>  	if (!dst)
>  		return -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708211537.371874-1-daniel@iogearbox.net?part=4