Re: [PATCH bpf-next 0/5] bpf: Expose pinned arenas as sized bpffs files

[Alexei Starovoitov]

On Fri, Oct 16, 2026 at 12:52 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
> kernel to do that. But once we have the ability to create ARRAY from a
> bunch of pre-existing memory (e.g., from memfd), this can be used both
> in a guest and in the host, and both models, guest allocates or host
> allocates, could be supported with the same model.

I don't think it will work for their use case.
With array of maps scx needs two lookups and two NULL checks
on every access, and the result cannot be kept in the task ctx
which is in arena today, since ptr_to_map_value becomes scalar.
unless everything is converted to magically bounded array, but...

> annoying, but what if we teach verifier to just automatically add
> bounds limiting sequence (e.g., masking if value size is power of two,
> slightly slower sequence for non-power-of-two, of course)

while working on arena ~year back I tried to add runtime masking to
ptr_to_map_value and couldn't figure it out.
then in ~april I tried again with llm-s and failed again.
the main issue is that ptr_to_map_value is a pointer,
and progs keep adding random stuff to it.
There is no way to split it into 'base + offset'
and apply mask on 'offset'.
I tried alignment tricks, like align each ptr_to_map_value's base
to 64k or such, but still failed. Something needs to remember
upper bits to see when math overflows.
That's why Barret was using explicit mask in C on every array access
(when he implemented all kinds of complex data structs on top of arrays).
Every access in C was base + mask(offset).

Array from memfd is a separate topic. So far I'm failing to see
a use case, but if it's not a lot of code, then why not.