Re: [PATCH v2 3/4] libbpf: offset global arena data into the arena if possible

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2025-12-01 at 13:34 -0500, Emil Tsalapatis wrote:

[...]

> > For (a), is there a way to move an address of first valid mmaped page
> > (from BPF perspective) w/o physically allocating the first page?
> > 
> 
> IIUC what you mean:
> 
> This is what this change combined with bpf_alloc_reserve_pages() amounts to.
> First, we adjust all the symbol addresses into the mapping to move the address
> out of the zero the page. Then, we call the existing bpf_alloc_reserve_pages()
> call to prevent the first page from ever being physically allocated.

libbpf.c:bpf_object__create_maps() allocates arena memory region as
follows:

  map->mmaped = mmap(addr: (void *)(long)map->map_extra, ...);

Where 'map_extra' comes from fill_map_from_def() / parse_btf_map_def().
The latter even provides a flag:

  map_def->parts |= MAP_DEF_MAP_EXTRA;

On the kernel side arena.c:arena_map_alloc() uses this 'map_extra' as
a starting arena address:

  arena->user_vm_start = attr->map_extra;

arena.c:arena_alloc_pages() uses 'user_vm_start' as follows:

  uaddr32 = (u32)(arena->user_vm_start + pgoff * PAGE_SIZE);
  ...
  return clear_lo32(val: arena->user_vm_start) + uaddr32;

Returned value is what BPF program sees as an address, right?
Is there a way to tweak arena_alloc_pages() implementation or arena
creation at libbpf side, such that arena_alloc_pages() never returns
value smaller then 16 * PAGE_SIZE?
E.g. by tweaking the attr->map_extra value in
bpf_object__create_maps() if it was not specified directly by user?

> Alternatively, if you maybe mean transparently add an offset to every
> arena address
>  in xlated/jitted code: That would also adjust the NULL pointers we're
> trying to catch
> to point to the first valid page we can allocate. In general, I don't
> think it's possible
> to do this in the verifier/JIT because this change depends on adjusting only
> the arena globals, and that is best done at load time.

For sure, it does not make sense to do it on verifier side.
It might even be impossible in general case.