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

[Andrii Nakryiko]

On Sat, Oct 17, 2026 at 5:52 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> 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.

fair enough

> 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'.

yeah, good point, some food for thought, I haven't thought much about
this, will keep it on backburner for now

> 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.

Yeah, there are just so many cases where we have some memory that is
special in some way (e.g., huge page-backed memory, or some IOMMU,
e.g., that doorbell stuff, which, if I understand correctly, is done
though writes to specially set up memory ranges), and we can't shove
all this into BPF_MAP_CREATE interface if we want to have BPF program
accessing that memory. So having a generic way to just bolt ARRAY on
top of already created memory seems like a useful primitive.

So we'll give it a try and see how it looks.