On 2/7/24 15:55, Alexei Starovoitov wrote:
instead of uaddr, can you change this to take an address relative to the arena ("arena virtual address"?)? the caller of this is in BPF, and they don't easily know the user virtual address. maybe even just pgoff directly.I thought about it, but it doesn't quite make sense. bpf prog only sees user addresses. All load/store returns them. If it bpf_printk-s an address it will be user address. bpf_arena_alloc_pages() also returns a user address.
Yeah, makes sense to keep them all in the same address space.
Kernel addresses are not seen by bpf prog at all. kern_vm_base is completely hidden. Only at JIT time, it's added to pointers. So passing uaddr to arena_alloc_pages() matches mmap style. uaddr = bpf_arena_alloc_pages(... uaddr ...) uaddr = mmap(uaddr, ...MAP_FIXED) Passing pgoff would be weird. Also note that there is no extra flag for bpf_arena_alloc_pages(). uaddr == full 64-bit of zeros is not a valid addr to use.
The problem I had with uaddr was that when I'm writing a BPF program, I don't know which address to use for a given page, e.g. the beginning of the arena. I needed some way to tell me the user address "base" of the arena. Though now that I can specify the user_vm_start through the map_extra, I think I'm ok.
Specifically, say I want to break up my arena into two, 2GB chunks, one for each numa node, and I want to bump-allocate from each chunk. When I want to allocate the first page from either segment, I'll need to know what user address is offset 0 or offset 2GB.
Since I know the user_start_vm at compile time, I can just hardcode that to convert from "arena address" (e.g. pgoff) to the user address space.
thanks, barret
