From: Emil Tsalapatis <emil@etsalapatis.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, eddyz87@gmail.com,
memxor@gmail.com, daniel@iogearbox.net,
Emil Tsalapatis <emil@etsalapatis.com>,
Puranjay Mohan <puranjay@kernel.org>
Subject: [PATCH bpf-next v2 0/7] bpf: Fix arena memory incoherence
Date: Wed, 23 Sep 2026 06:14:18 +0000 [thread overview]
Message-ID: <20260923061425.7045-1-emil@etsalapatis.com> (raw)
Setting up arena memory for a task currently requires two operations:
Adjusting its range tree, used for tracking which memory is allocated;
and adjusting its page tables/flushing its TLB state. These operations
cannot happen atomically because their critical sections do not nest.
This lack of atomicity is the source of two bugs that can lead to
incoherence between different users of the same arena, wherein they
observe different pages for the same address.
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.
Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
Cc: Puranjay Mohan <puranjay@kernel.org>
v1 -> v2 (https://lore.kernel.org/bpf/20260902070239.16968-1-emil@etsalapatis.com/)
- Use __range_iter_next() in is_range_tree_set() (bot-ci)
- Move -EAGAIN handling to the patch where the errno is introduced (bot-ci)
- Add refactoring patch for (Puranjay)
- Avoid leaking unavailable range tree nodes with atomic mark_available
operation()
- Avoid retries on res spinlock locking for -EDEADLK (Puranjay)
---
Emil Tsalapatis (7):
bpf: Update is_range_tree_set to work for consecutive ranges
bpf: Track availability information for ranges in range tree
bpf: Fix arena race between page free and alloc leading to incoherency
bpf: Add explicit state machine for arena free spans
bpf: Atomically update PTE and range tree in arena VM fault handler
bpf: Avoid unavailable range leakage during arena_free_pages()
selftests/bpf: Add arena allocation race tests
kernel/bpf/arena.c | 223 +++++++++++++--
kernel/bpf/range_tree.c | 237 ++++++++++++---
kernel/bpf/range_tree.h | 8 +-
.../selftests/bpf/prog_tests/arena_race.c | 270 ++++++++++++++++++
.../testing/selftests/bpf/progs/arena_race.c | 159 +++++++++++
5 files changed, 839 insertions(+), 58 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/arena_race.c
create mode 100644 tools/testing/selftests/bpf/progs/arena_race.c
---
NOTE: This version has two additional patches, one NFC one a fix for an
issue introduced in this series while fixing another. For the former, I
think we should keep it as a separate patch to make it more clear what
each change does. The latter is murkier - we can avoid the temporary
regression by spreading Patch 6 into Patches 2 and 3 if need be.
--
2.54.0
next reply other threads:[~2026-09-23 6:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 6:14 Emil Tsalapatis [this message]
2026-09-23 6:14 ` [PATCH bpf-next v2 1/7] bpf: Update is_range_tree_set to work for consecutive ranges Emil Tsalapatis
2026-09-23 6:14 ` [PATCH bpf-next v2 2/7] bpf: Track availability information for ranges in range tree Emil Tsalapatis
2026-09-23 6:14 ` [PATCH bpf-next v2 3/7] bpf: Fix arena race between page free and alloc leading to incoherency Emil Tsalapatis
2026-09-23 6:14 ` [PATCH bpf-next v2 4/7] bpf: Add explicit state machine for arena free spans Emil Tsalapatis
2026-09-23 6:14 ` [PATCH bpf-next v2 5/7] bpf: Atomically update PTE and range tree in arena VM fault handler Emil Tsalapatis
2026-09-23 6:14 ` [PATCH bpf-next v2 6/7] bpf: Avoid unavailable range leakage during arena_free_pages() Emil Tsalapatis
2026-09-23 6:14 ` [PATCH bpf-next v2 7/7] selftests/bpf: Add arena allocation race tests Emil Tsalapatis
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=20260923061425.7045-1-emil@etsalapatis.com \
--to=emil@etsalapatis.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox