On Wed, Feb 14, 2024 at 12:36 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > NAK. Please What is the alternative? Remember, maintainers cannot tell developers "go away". They must suggest a different path. > On Thu, Feb 08, 2024 at 08:05:52PM -0800, Alexei Starovoitov wrote: > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > BPF would like to use the vmap API to implement a lazily-populated > > memory space which can be shared by multiple userspace threads. > > The vmap API is generally public and has functions to request and > > What is "the vmap API"? I mean an API that manages kernel virtual address space: . get_vm_area - external . free_vm_area - EXPORT_SYMBOL_GPL . vunmap_range - external . vmalloc_to_page - EXPORT_SYMBOL . apply_to_page_range - EXPORT_SYMBOL_GPL and the last one is pretty much equivalent to vmap_pages_range, hence I'm surprised by push back to make vmap_pages_range available to bpf. > > For example, there is the public ioremap_page_range(), which is used > > to map device memory into addressable kernel space. > > It's not really public. It's a helper for the ioremap implementation > which really should not be arch specific to start with and are in > the process of beeing consolidatd into common code. Any link to such consolidation of ioremap ? I couldn't find one. I surely don't want bpf_arena to cause headaches to mm folks. Anyway, ioremap_page_range() was just an example. I could have used vmap() as an equivalent example. vmap is EXPORT_SYMBOL, btw. What bpf_arena needs is pretty much vmap(), but instead of allocating all pages in advance, allocate them and insert on demand. As you saw in the next patch bpf_arena does: get_vm_area(4Gbyte, VM_MAP | VM_USERMAP); and then alloc_page + vmap_pages_range into this region on demand. Nothing fancy. > > The new BPF code needs the functionality of vmap_pages_range() in > > order to incrementally map privately managed arrays of pages into its > > vmap area. Indeed this function used to be public, but became private > > when usecases other than vmalloc happened to disappear. > > Yes, for a freaking good reason. The vmap area is not for general abuse > by random callers. We have a few of those left, but we need to get rid > of that and not add more. What do you mean by "vmap area" ? The vmalloc virtual region ? Are you suggesting that bpf_arena should reserve its own virtual region of kernel memory instead of vmalloc region ? That's doable, but I don't quite see the point. Instead of VMALLOC_START/END we can carve a bpf specific region and do __get_vm_area_node() from there, but why? vmalloc region fits the best. bpf_arena's mm manipulations don't interfere with kasan either. Or you meant vm_map_ram() ? Don't care about those. bpf_arena doesn't touch that.
