From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Emil Tsalapatis" <emil@etsalapatis.com>, <bpf@vger.kernel.org>
Cc: <andrii@kernel.org>, <eddyz87@gmail.com>, <memxor@gmail.com>,
<daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next v4 7/8] bpf: Synchronize arena page faults with page freeing
Date: Fri, 16 Oct 2026 02:02:58 +0000 [thread overview]
Message-ID: <DM5W5YU16482.21ASVI86YUGIR@gmail.com> (raw)
In-Reply-To: <20261014233442.8392-8-emil@etsalapatis.com>
On Wed, Oct 14, 2026 at 11:34 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
> Prevent the arena VM fault handler from running in parallel with arena free
> operations. This is similar to the policy for file-backed mappings. Use a
> per-arena reference counter to exclude faults from synchronous and deferred
> page teardown, and vice versa. Faults and frees can each run concurrently
> with operations of the same type.
In v3 I suggested to lock the page, recheck vmalloc_to_page() and
return VM_FAULT_LOCKED. The recheck is missing and opref is there
instead of it.
The free path clears the pte under arena->spinlock and then does
lock_page(); unlock_page();
If arena_vm_fault() locked the page first the free waits for
finish_fault() and zap_pages() removes that pte.
If the free was first arena_vm_fault() sees different vmalloc_to_page()
under the page lock. Unlock, put and start over.
The fault holds a page ref, so the same page cannot come back.
The free path holds nothing when it gets to zap_pages(), so
mmap_read_lock() there is fine and patch 1 is not needed.
See
commit bb9b9eb0ae2e ("scsi: target: tcmu: Fix possible data corruption").
Same bug.
[...]
> if (!sleepable)
> goto defer;
> + if (!arena_opref_get(arena, ARENA_OPREF_FREE))
> + goto defer;
One user thread faulting on any page of the arena turns sleepable
bpf_arena_free_pages() of unrelated page into deferred one.
buddy_chunk_get() in libarena does
bpf_arena_free_pages(vaddr); bpf_arena_alloc_pages(vaddr);
The alloc fails and that vaddr is lost.
The other way around any free makes all faults in the arena spin in
VM_FAULT_RETRY, and the worker spins in schedule_work() while a fault
sleeps in alloc_pages_node(GFP_KERNEL).
Giving frees a priority over faults, as you replied to bpf-ci, makes it
even heavier.
next prev parent reply other threads:[~2026-10-16 2:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 23:34 [PATCH bpf-next v4 0/8] bpf: Fix arena memory incoherence Emil Tsalapatis
2026-10-14 23:34 ` [PATCH bpf-next v4 1/8] bpf: Use mapping tree to zap arena VMAs Emil Tsalapatis
2026-10-15 0:33 ` bot+bpf-ci
2026-10-15 15:02 ` Emil Tsalapatis
2026-10-16 2:02 ` Alexei Starovoitov
2026-10-14 23:34 ` [PATCH bpf-next v4 2/8] bpf: Associate arena pages with their mapping Emil Tsalapatis
2026-10-15 0:01 ` sashiko-bot
2026-10-15 15:15 ` Emil Tsalapatis
2026-10-16 2:02 ` Alexei Starovoitov
2026-10-14 23:34 ` [PATCH bpf-next v4 3/8] bpf: arena: Stop deferred frees before map teardown Emil Tsalapatis
2026-10-14 23:34 ` [PATCH bpf-next v4 4/8] bpf: Update is_range_tree_set to work for consecutive ranges Emil Tsalapatis
2026-10-14 23:34 ` [PATCH bpf-next v4 5/8] bpf: Track availability information for ranges in range tree Emil Tsalapatis
2026-10-14 23:34 ` [PATCH bpf-next v4 6/8] bpf: Fix arena race between page free and alloc leading to incoherency Emil Tsalapatis
2026-10-16 2:02 ` Alexei Starovoitov
2026-10-14 23:34 ` [PATCH bpf-next v4 7/8] bpf: Synchronize arena page faults with page freeing Emil Tsalapatis
2026-10-15 0:33 ` bot+bpf-ci
2026-10-15 15:18 ` Emil Tsalapatis
2026-10-16 2:02 ` Alexei Starovoitov [this message]
2026-10-14 23:34 ` [PATCH bpf-next v4 8/8] selftests/bpf: Add arena allocation race tests Emil Tsalapatis
2026-10-14 23:52 ` sashiko-bot
2026-10-16 0:03 ` [PATCH bpf-next v4 0/8] bpf: Fix arena memory incoherence Emil Tsalapatis
2026-10-16 0:04 ` Emil Tsalapatis
2026-10-16 2:03 ` Alexei Starovoitov
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=DM5W5YU16482.21ASVI86YUGIR@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=memxor@gmail.com \
/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.