From: Breno Leitao <leitao@debian.org>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH] bpf: arena: reschedule while freeing the arena pages
Date: Tue, 25 Aug 2026 07:06:02 -0700 [thread overview]
Message-ID: <ao2gP7Y6UJ2o2tUc@gmail.com> (raw)
In-Reply-To: <20260824170831.33E051F000E9@smtp.kernel.org>
On Mon, Aug 24, 2026 at 05:08:30PM +0000, sashiko-bot@kernel.org wrote:
> > diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
> > index 7b6847200b431..c5f6bebbb15c3 100644
> > --- a/kernel/bpf/arena.c
> > +++ b/kernel/bpf/arena.c
> > @@ -364,6 +364,7 @@ static int existing_page_cb(pte_t *ptep, unsigned long addr, void *data)
> > * the freed page. So it all relies on 1.
> > */
> > __free_page(page);
> > + cond_resched();
>
> [Severity: High]
> Does adding cond_resched() here violate the lazy MMU mode contract?
>
> The callback existing_page_cb() is a pte_fn_t called by apply_to_pte_range(),
> which establishes an atomic context by wrapping the callback loop in
> lazy_mmu_mode_enable():
>
> mm/memory.c:apply_to_pte_range() {
> ...
> lazy_mmu_mode_enable();
> if (fn) {
> do {
> if (create || !pte_none(ptep_get(pte))) {
> err = fn(pte, addr, data);
> ...
> }
>
> On architectures like PowerPC64 with hash MMUs, lazy_mmu_mode_enable()
> explicitly disables preemption. Since preemption is disabled, cond_resched()
> evaluates to a no-op, which means it won't actually yield the CPU and will
> fail to resolve the original softlockup.
>
> Additionally, if CONFIG_DEBUG_ATOMIC_SLEEP is enabled, this could trigger a
> "sleeping function called from invalid context" bug during teardown.
That is a good point, I think a better approach would be to drop the
cond_resched() from the callback -- existing_page_cb() goes back to its
original form.
Then we walks the range in chunks from arena_map_free() instead, so the
resched happens outside the lazy MMU section (FREE_CHUNK_SZ is SZ_64M):
addr = bpf_arena_get_kern_vm_start(arena);
end = addr + SZ_4G + GUARD_SZ / 2;
while (addr < end) {
u64 size = min_t(u64, end - addr, FREE_CHUNK_SZ);
apply_to_existing_page_range(&init_mm, addr, size,
existing_page_cb, arena);
cond_resched();
addr += size;
}
Would this be a better approach?
--breno
next prev parent reply other threads:[~2026-08-25 14:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 16:54 [PATCH] bpf: arena: reschedule while freeing the arena pages Breno Leitao
2026-08-24 17:08 ` sashiko-bot
2026-08-25 14:06 ` Breno Leitao [this message]
2026-08-25 16:35 ` Alexei Starovoitov
2026-08-26 10:03 ` Breno Leitao
2026-08-24 17:48 ` bot+bpf-ci
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=ao2gP7Y6UJ2o2tUc@gmail.com \
--to=leitao@debian.org \
--cc=bpf@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.