Re: [PATCH v4 bpf-next 1/2] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range.

On Fri, Mar 8, 2024 at 9:14 AM Marek Szyprowski wrote: > > On 05.03.2024 04:05, Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > > > There are various users of get_vm_area() + ioremap_page_range() APIs. > > Enforce that get_vm_area() was requeste

Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

On Wed, Mar 6, 2024 at 2:57 PM Pasha Tatashin wrote: > > On Wed, Mar 6, 2024 at 5:13 PM Alexei Starovoitov > wrote: > > > > On Wed, Mar 6, 2024 at 1:46 PM Pasha Tatashin > > wrote: > > > > > > > > This interface and in general VM_SPARSE wou

Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

On Wed, Mar 6, 2024 at 1:46 PM Pasha Tatashin wrote: > > > > This interface and in general VM_SPARSE would be useful for > > > dynamically grown kernel stacks [1]. However, the might_sleep() here > > > would be a problem. We would need to be able to handle > > > vm_area_map_pages() from interrupt

Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

On Wed, Mar 6, 2024 at 1:04 PM Pasha Tatashin wrote: > > On Mon, Mar 4, 2024 at 10:05 PM Alexei Starovoitov > wrote: > > > > From: Alexei Starovoitov > > > > vmap/vmalloc APIs are used to map a set of pages into contiguous kernel > > virtual space. >

Re: [PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

On Wed, Mar 6, 2024 at 6:19 AM Christoph Hellwig wrote: > > I'd still prefer to hide the vm_area, but for now: > > Reviewed-by: Christoph Hellwig Thank you. I will think of a way to move get_vm_area() to mm/internal.h and propose a plan by lsf/mm/bpf in May.

[PATCH v4 bpf-next 1/2] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range.

From: Alexei Starovoitov There are various users of get_vm_area() + ioremap_page_range() APIs. Enforce that get_vm_area() was requested as VM_IOREMAP type and range passed to ioremap_page_range() matches created vm_area to avoid accidentally ioremap-ing into wrong address range. Reviewed

[PATCH v4 bpf-next 2/2] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

From: Alexei Starovoitov vmap/vmalloc APIs are used to map a set of pages into contiguous kernel virtual space. get_vm_area() with appropriate flag is used to request an area of kernel address range. It's used for vmalloc, vmap, ioremap, xen use cases. - vmalloc use case dominates the usage

[PATCH v4 bpf-next 0/2] mm: Enforce ioremap address space and introduce sparse vm_area

From: Alexei Starovoitov 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

Re: [PATCH v2 bpf-next 2/3] mm, xen: Separate xen use cases from ioremap.

On Sun, Mar 3, 2024 at 11:55 PM Mike Rapoport wrote: > > On Fri, Feb 23, 2024 at 03:57:27PM -0800, Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > > > xen grant table and xenbus ring are not ioremap the way arch specific code > > is using it, > >

[PATCH v3 bpf-next 3/3] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

From: Alexei Starovoitov vmap/vmalloc APIs are used to map a set of pages into contiguous kernel virtual space. get_vm_area() with appropriate flag is used to request an area of kernel address range. It'se used for vmalloc, vmap, ioremap, xen use cases. - vmalloc use case dominates the usage

[PATCH v3 bpf-next 1/3] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range.

From: Alexei Starovoitov There are various users of get_vm_area() + ioremap_page_range() APIs. Enforce that get_vm_area() was requested as VM_IOREMAP type and range passed to ioremap_page_range() matches created vm_area to avoid accidentally ioremap-ing into wrong address range. Reviewed

[PATCH v3 bpf-next 2/3] mm, xen: Separate xen use cases from ioremap.

From: Alexei Starovoitov xen grant table and xenbus ring are not ioremap the way arch specific code is using it, so let's add VM_XEN flag to separate these use cases from VM_IOREMAP users. xen will not and should not be calling ioremap_page_range() on that range. /proc/vmallocinfo will print

[PATCH v3 bpf-next 0/3] mm: Cleanup and identify various users of kernel virtual address space

From: Alexei Starovoitov 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,

Re: [PATCH v2 bpf-next 3/3] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

On Tue, Feb 27, 2024 at 9:59 AM Christoph Hellwig wrote: > > > privately-managed pages into a sparse vm area with the following steps: > > > > area = get_vm_area(area_size, VM_SPARSE); // at bpf prog verification > > time > > vm_area_map_pages(area, kaddr, 1, page); // on demand > >

[PATCH v2 bpf-next 3/3] mm: Introduce VM_SPARSE kind and vm_area_[un]map_pages().

From: Alexei Starovoitov vmap/vmalloc APIs are used to map a set of pages into contiguous kernel virtual space. get_vm_area() with appropriate flag is used to request an area of kernel address range. It'se used for vmalloc, vmap, ioremap, xen use cases. - vmalloc use case dominates the usage

[PATCH v2 bpf-next 1/3] mm: Enforce VM_IOREMAP flag and range in ioremap_page_range.

From: Alexei Starovoitov There are various users of get_vm_area() + ioremap_page_range() APIs. Enforce that get_vm_area() was requested as VM_IOREMAP type and range passed to ioremap_page_range() matches created vm_area to avoid accidentally ioremap-ing into wrong address range. Signed-off

[PATCH v2 bpf-next 2/3] mm, xen: Separate xen use cases from ioremap.

From: Alexei Starovoitov xen grant table and xenbus ring are not ioremap the way arch specific code is using it, so let's add VM_XEN flag to separate them from VM_IOREMAP users. xen will not and should not be calling ioremap_page_range() on that range. /proc/vmallocinfo will print such region

[PATCH v2 bpf-next 0/3] mm: Cleanup and identify various users of kernel virtual address space

From: Alexei Starovoitov 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