From: Alexei Starovoitov <ast@xxxxxxxxxx> v3 -> v4 - dropped VM_XEN patch for now. It will be in the follow up. - fixed constant as pointed out by Mike v2 -> v3 - added Christoph's reviewed-by to patch 1 - cap commit log lines to 75 chars - factored out common checks in patch 3 into helper - made vm_area_unmap_pages() return void There are various users of kernel virtual address space: vmalloc, vmap, ioremap, xen. - vmalloc use case dominates the usage. Such vm areas have VM_ALLOC flag and these areas are treated differently by KASAN. - the areas created by vmap() function should be tagged with VM_MAP (as majority of the users do). - ioremap areas are tagged with VM_IOREMAP and vm area start is aligned to size of the area unlike vmalloc/vmap. - there is also xen usage that is marked as VM_IOREMAP, but it doesn't call ioremap_page_range() unlike all other VM_IOREMAP users. To clean this up a bit, enforce that ioremap_page_range() checks the range and VM_IOREMAP flag. In addition BPF would like to reserve regions of kernel virtual address space and populate it lazily, similar to xen use cases. For that reason, introduce VM_SPARSE flag and vm_area_[un]map_pages() helpers to populate this sparse area. In the end the /proc/vmallocinfo will show "vmalloc" "vmap" "ioremap" "sparse" categories for different kinds of address regions. ioremap, sparse will return zero when dumped through /proc/kcore Alexei Starovoitov (2): mm: Enforce VM_IOREMAP flag and range in ioremap_page_range. mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages(). include/linux/vmalloc.h | 5 +++ mm/vmalloc.c | 72 +++++++++++++++++++++++++++++++++++++++-- 2 files changed, 75 insertions(+), 2 deletions(-) -- 2.43.0
