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>, "Puranjay Mohan" <puranjay@kernel.org>
Subject: Re: [PATCH bpf-next v4 0/8] bpf: Fix arena memory incoherence
Date: Fri, 16 Oct 2026 02:03:21 +0000 [thread overview]
Message-ID: <DM5W696SHG8H.2O783XL6H1PG2@gmail.com> (raw)
In-Reply-To: <20261014233442.8392-1-emil@etsalapatis.com>
On Wed, Oct 14, 2026 at 11:34 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
> Address the problem by more finely tracking the state of each address.
> Expand the range tree used for address state tracking with a third
> state, used to denote whether an address range is unavailable, either
> because it is being freed or because it is being populated by a VM
> fault. Use this extra state in the arena page freeing/fault logic
> to ensure that operations on a single address properly serialize.
In v3 I asked to keep the range allocated until flush_tlb_kernel_range()
and zap_pages() are done instead of adding the 3rd state.
You replied that arena_vm_fault() would need a marker similar to
the 3rd state to skip such range:
https://lore.kernel.org/bpf/CABFh=a7z3pdJy6LW+Kc3sQ+chp7iun8t3x+XH2OmuSKNFN6icg@mail.gmail.com/
It doesn't. The range tree has it already.
When vmalloc_to_page() is NULL and is_range_tree_set(pgoff, 1) fails
the page is either reserved or being freed.
Return the same error as for scratch_page few lines above.
The free path does range_tree_clear() and clears ptes under the lock,
then flush, zap, and range_tree_set() at the end.
range_tree_clear() allocates only when the range sits in the middle of
a free range, so nothing is allocated before the pages are unmapped.
Disabling bpf_arena_alloc/free_pages() without BPF_F_SEGV_ON_FAULT
is not an option. Nothing in selftests, libarena or tools/sched_ext
sets that flag.
[...]
> - Add per-arena anonymous mappings and associate pages with them
> - Return VM_FAULT_LOCKED and let generic MM install user PTEs; wait
> for locked fault pages before TLB flushing and zapping (Alexei).
> - Add mutual exclusion between arena free and fault operations to
> prevent incoherency.
v3 was +851 lines. v4 is +1013.
On top of the 3rd state there are span flags, opref with a wait queue,
an inode per arena, page->mapping and a new bpf_map_ops callback.
These are two ordering bugs. See replies to patches 1, 2, 6, 7.
pw-bot: cr
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
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 [this message]
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=DM5W696SHG8H.2O783XL6H1PG2@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 \
--cc=puranjay@kernel.org \
/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.