On Mon, Nov 20, 2023 at 09:59:24AM -0800, Dave Marchevsky wrote: > This patch modifies the generic bpf_local_storage infrastructure to > support mmapable map values and adds mmap() handling to task_local > storage leveraging this new functionality. A userspace task which > mmap's a task_local storage map will receive a pointer to the map_value > corresponding to that tasks' key - mmap'ing in other tasks' mapvals is > not supported in this patch. > > Currently, struct bpf_local_storage_elem contains both bookkeeping > information as well as a struct bpf_local_storage_data with additional > bookkeeping information and the actual mapval data. We can't simply map > the page containing this struct into userspace. Instead, mmapable > local_storage uses bpf_local_storage_data's data field to point to the > actual mapval, which is allocated separately such that it can be > mmapped. Only the mapval lives on the page(s) allocated for it. > > The lifetime of the actual_data mmapable region is tied to the > bpf_local_storage_elem which points to it. This doesn't necessarily mean > that the pages go away when the bpf_local_storage_elem is free'd - if > they're mapped into some userspace process they will remain until > unmapped, but are no longer the task_local storage's mapval. Those bits look good to me. vfree() uses __free_pages(), which participates in refcounting. remap_vmalloc_range() acquires references to the individual pages, which will be dropped once the page tables disappear on munmap(). The vmalloc area doesn't need to stick around.
