From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Emil Tsalapatis" <emil@etsalapatis.com>
Cc: "Tejun Heo" <tj@kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"David Vernet" <void@manifault.com>,
"Andrea Righi" <arighi@nvidia.com>,
"Changwoo Min" <changwoo@igalia.com>, <bpf@vger.kernel.org>,
<sched-ext@lists.linux.dev>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 2/9] bpf/arena: Add BPF_F_ARENA_MAP_ALWAYS for direct kernel access
Date: Mon, 11 May 2026 20:25:03 -0700 [thread overview]
Message-ID: <DIGDLA5275AR.128FTQMU7Z8S3@gmail.com> (raw)
In-Reply-To: <CAP01T77_Lgfj8yX6JtErGES9icebqygDUZT-wzXq9UV6JGugYA@mail.gmail.com>
On Mon May 11, 2026 at 7:43 PM PDT, Kumar Kartikeya Dwivedi wrote:
>
> If not, the best course to me seems to be to make the flag behavior
> default, and just rely on ASan (and Rust in the future) to prevent any
> memory safety issues, and drop the stream based feedback on fault,
> etc.
Agree that this needs to be new default without new uapi flags.
How about we tweak the idea further.
Let all arena pages be unmapped initially. bpf progs will fault
on them and will be reported via bpf_streams.
But we also prepare one "scratch page". Let's use this name,
since "garbage page" reads too dirty.
When kernel faults we populate pte with that scratch page
and let the kernel code retry.
To implement it the page_fault_oops() can have a callback
into bpf/arena helper similar to kfence_handle_page_fault.
If fault address is in arena, do kfence_unprotect()-like.
next prev parent reply other threads:[~2026-05-12 3:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260427105109.2554518-1-tj@kernel.org>
[not found] ` <20260427105109.2554518-6-tj@kernel.org>
2026-05-11 21:44 ` [RFC PATCH 5/9] bpf: Add bpf_prog_for_each_used_map() Kumar Kartikeya Dwivedi
[not found] ` <20260427105109.2554518-3-tj@kernel.org>
2026-05-12 0:31 ` [RFC PATCH 2/9] bpf/arena: Add BPF_F_ARENA_MAP_ALWAYS for direct kernel access Kumar Kartikeya Dwivedi
2026-05-12 2:05 ` Emil Tsalapatis
2026-05-12 2:43 ` Kumar Kartikeya Dwivedi
2026-05-12 3:25 ` Alexei Starovoitov [this message]
2026-05-12 3:48 ` Kumar Kartikeya Dwivedi
2026-05-12 4:24 ` Alexei Starovoitov
2026-05-12 12:29 ` Emil Tsalapatis
2026-05-12 14:07 ` Kumar Kartikeya Dwivedi
2026-05-12 15:59 ` Emil Tsalapatis
2026-05-12 3:42 ` 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=DIGDLA5275AR.128FTQMU7Z8S3@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=arighi@nvidia.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=changwoo@igalia.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=memxor@gmail.com \
--cc=sched-ext@lists.linux.dev \
--cc=tj@kernel.org \
--cc=void@manifault.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox