BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jim Cromie" <jim.cromie@gmail.com>
Cc: dri-devel@lists.freedesktop.org, bpf@vger.kernel.org
Subject: Re: [PATCH 3/9] bpf/verifier: Route verifier stack state node allocations to folio_pool
Date: Mon, 17 Aug 2026 17:35:07 +0000	[thread overview]
Message-ID: <20260817173508.44AE71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260817-folio-pool-v1-v1-3-0c1d230aa3af@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unbounded bump-allocation of `bpf_verifier_stack_elem` causes severe transient memory bloat during BPF verification.
--

--- Patch [3]: [PATCH 3/9] bpf/verifier: Route verifier stack state node allocations to folio_pool ---
commit 1f1ee699bf3c9e5a960869e7d6dbd7c57b050ee5
Author: Jim Cromie <jim.cromie@gmail.com>

bpf/verifier: Route verifier stack state node allocations to folio_pool

This commit embeds a folio_pool inside bpf_verifier_env to allocate transient
bpf_verifier_stack_elem frames, releasing them in bulk at the end of
bpf_check().

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -1725,7 +1725,7 @@ static int pop_stack(struct bpf_verifier_env *env, int *prev_insn_idx,
>  		*prev_insn_idx = head->prev_insn_idx;
>  	elem = head->next;
>  	bpf_free_verifier_state(&head->st, false);
> -	kfree(head);
> +	folio_pool_free_elem(head);

[Severity: High]
Does this cause unbounded memory growth during verification?

Looking at include/linux/folio_pool.h, folio_pool_free_elem() appears to be a
no-op for pointers allocated from the pool:

static inline void folio_pool_free_elem(const void *ptr)
{
	if (!ptr || is_folio_pool_ptr(ptr))
		return;
	kvfree(ptr);
}

Since elements popped from the verifier stack are not actually freed, won't
the memory consumption scale with the total number of branches explored
rather than the maximum depth of the verification stack?

>  	env->head = elem;
>  	env->stack_size--;
>  	return 0;

[ ... ]

> @@ -1751,7 +1753,9 @@ static struct bpf_verifier_state *push_stack(struct bpf_verifier_env *env,
>  	struct bpf_verifier_stack_elem *elem;
>  	int err;
>  
> -	elem = kzalloc_obj(struct bpf_verifier_stack_elem, GFP_KERNEL_ACCOUNT);
> +	elem = folio_pool_alloc_obj(env, state_pool,
> +				    struct bpf_verifier_stack_elem,
> +				    GFP_KERNEL_ACCOUNT);

[Severity: High]
With every explored branch allocating a new stack element here, and
pop_stack() abandoning the memory, can this transient memory bloat lead to
memory exhaustion and potential OOMs when verifying complex BPF programs
with many branches?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260817-folio-pool-v1-v1-0-0c1d230aa3af@gmail.com?part=3

  reply	other threads:[~2026-08-17 17:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 17:22 [PATCH 0/9] lib/folio_pool: Direct-Map Large Folio Pool & Scratchpad bump allocators Jim Cromie via B4 Relay
2026-08-17 17:22 ` [PATCH 1/9] lib/folio_pool: Introduce " Jim Cromie via B4 Relay
2026-08-17 17:33   ` sashiko-bot
2026-08-17 17:22 ` [PATCH 2/9] netfilter/nf_tables: Add folio_scratchpad collector to struct nftables_pernet Jim Cromie via B4 Relay
2026-08-17 17:35   ` sashiko-bot
2026-08-17 17:22 ` [PATCH 3/9] bpf/verifier: Route verifier stack state node allocations to folio_pool Jim Cromie via B4 Relay
2026-08-17 17:35   ` sashiko-bot [this message]
2026-08-17 17:22 ` [PATCH 4/9] drm/gpuvm: Route gpuva_op allocations to folio_scratchpad Jim Cromie via B4 Relay
2026-08-17 17:31   ` sashiko-bot
2026-08-17 17:22 ` [PATCH 5/9] bpf/syscall: Route generic_map_update_batch key/value " Jim Cromie via B4 Relay
2026-08-17 17:32   ` sashiko-bot
2026-08-17 17:22 ` [PATCH 6/9] locking/lockdep: Fallback to folio_pool in alloc_list_entry when static pool is full Jim Cromie via B4 Relay
2026-08-17 17:36   ` sashiko-bot
2026-08-17 21:01   ` Peter Zijlstra
2026-08-17 17:22 ` [PATCH 7/9] locking/lockdep: Traverse adjacency lists directly in zap_class() Jim Cromie via B4 Relay
2026-08-17 17:39   ` sashiko-bot
2026-08-17 17:22 ` [PATCH 8/9] locking/lockdep: Shrink static list_entries array to early bootstrap buffer Jim Cromie via B4 Relay
2026-08-17 17:52   ` sashiko-bot
2026-08-17 17:22 ` [PATCH 9/9] locking/lockdep: Migrate and compact boot-time dependency graph from __initdata Jim Cromie via B4 Relay
2026-08-17 17:45   ` sashiko-bot
2026-08-17 18:17 ` [PATCH 0/9] lib/folio_pool: Direct-Map Large Folio Pool & Scratchpad bump allocators David Hildenbrand (Arm)
2026-08-17 18:34 ` Matthew Wilcox

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=20260817173508.44AE71F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jim.cromie@gmail.com \
    --cc=sashiko-reviews@lists.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