Re: [PATCH 06/10] mm: move __remove_vm_area out of va_remove_mappings

[Uladzislau Rezki <urezki@gmail.com>]

On Thu, Jan 19, 2023 at 11:02:22AM +0100, Christoph Hellwig wrote:
> __remove_vm_area is the only part of va_remove_mappings that requires
> a vmap_area.  Move the call out to the caller and only pass the vm_struct
> to va_remove_mappings.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  mm/vmalloc.c | 10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3c07520b8b821b..09c6fcfdaeb7c9 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2614,18 +2614,15 @@ static inline void set_area_direct_map(const struct vm_struct *area,
>  			set_direct_map(area->pages[i]);
>  }
>  
> -/* Handle removing and resetting vm mappings related to the VA's vm_struct. */
> -static void va_remove_mappings(struct vmap_area *va, int deallocate_pages)
> +/* Handle removing and resetting vm mappings related to the vm_struct. */
> +static void va_remove_mappings(struct vm_struct *area, int deallocate_pages)
>  {
> -	struct vm_struct *area = va->vm;
>  	unsigned long start = ULONG_MAX, end = 0;
>  	unsigned int page_order = vm_area_page_order(area);
>  	int flush_reset = area->flags & VM_FLUSH_RESET_PERMS;
>  	int flush_dmap = 0;
>  	int i;
>  
> -	__remove_vm_area(va);
> -
>  	/* If this is not VM_FLUSH_RESET_PERMS memory, no need for the below. */
>  	if (!flush_reset)
>  		return;
> @@ -2691,7 +2688,8 @@ static void __vunmap(const void *addr, int deallocate_pages)
>  
>  	kasan_poison_vmalloc(area->addr, get_vm_area_size(area));
>  
> -	va_remove_mappings(va, deallocate_pages);
> +	__remove_vm_area(va);
> +	va_remove_mappings(area, deallocate_pages);
>  
>  	if (deallocate_pages) {
>  		int i;
> -- 
> 2.39.0
> 
A small nit here. IMHO, a va_remove_mappings() should be
renamed back to vm_remove_mappings() since after this patch
it starts deal with "struct vm_struct".

OK. After checking all patches this function will be renamed
anyway to vm_reset_perms().

Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>

--
Uladzislau Rezki