linux-kernel - Re: [PATCH v2] mm/mmap: convert all mas except mas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 26 Feb 2024 13:00:36 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Helge Deller <deller@....de>
Cc: Yajun Deng <yajun.deng@...ux.dev>, akpm@...ux-foundation.org,
        vbabka@...e.cz, lstoakes@...il.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/mmap: convert all mas except mas_detach to vma
 iterator

> There are two types of iterators mas and vmi in the current code. If the
> maple tree comes from the mm struct, we can use the vma iterator. Avoid
> using mas directly as possible.
> 

Helge,

Yajun has changed code that affects parisc with this patch, which hasn't
been tested.



* Yajun Deng <yajun.deng@...ux.dev> [240226 01:16]:
> Keep using mas for the mt_detach tree, since it doesn't come from the mm
> struct.
> 
> Remove as many mas uses as feasible, but we will still have a few that
> must be passed through in unmap_vmas() and free_pgtables().
> 
> Also introduce vma_iter_reset, vma_iter_{prev, next}_range_limit and
> vma_iter_area_{lowest, highest} helper functions for using vma interator.
> 
> Signed-off-by: Yajun Deng <yajun.deng@...ux.dev>
> ---
> v2: Add vma_iter_reset() and vma_iter_{prev, next}_range_limit() helper functions.
> v1: https://lore.kernel.org/all/9f76ce23-67b1-ccbe-a722-1db0e8f0a408@linux.dev/
> ---

..

>  
> @@ -1975,7 +1974,7 @@ static int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  	struct vm_area_struct *next;
>  	unsigned long gap_addr;
>  	int error = 0;
> -	MA_STATE(mas, &mm->mm_mt, vma->vm_start, address);
> +	VMA_ITERATOR(vmi, mm, vma->vm_start);
>  
>  	if (!(vma->vm_flags & VM_GROWSUP))
>  		return -EFAULT;
> @@ -2001,15 +2000,15 @@ static int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  	}
>  
>  	if (next)
> -		mas_prev_range(&mas, address);
> +		vma_iter_prev_range_limit(&vmi, address);
>  
> -	__mas_set_range(&mas, vma->vm_start, address - 1);
> -	if (mas_preallocate(&mas, vma, GFP_KERNEL))
> +	vma_iter_config(&vmi, vma->vm_start, address);
> +	if (vma_iter_prealloc(&vmi, vma))
>  		return -ENOMEM;
>  
>  	/* We must make sure the anon_vma is allocated. */
>  	if (unlikely(anon_vma_prepare(vma))) {
> -		mas_destroy(&mas);
> +		vma_iter_free(&vmi);
>  		return -ENOMEM;
>  	}
>  
> @@ -2049,7 +2048,7 @@ static int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  				anon_vma_interval_tree_pre_update_vma(vma);
>  				vma->vm_end = address;
>  				/* Overwrite old entry in mtree. */
> -				mas_store_prealloc(&mas, vma);
> +				vma_iter_store(&vmi, vma);
>  				anon_vma_interval_tree_post_update_vma(vma);
>  				spin_unlock(&mm->page_table_lock);
>  
> @@ -2058,7 +2057,7 @@ static int expand_upwards(struct vm_area_struct *vma, unsigned long address)
>  		}
>  	}
>  	anon_vma_unlock_write(vma->anon_vma);
> -	mas_destroy(&mas);
> +	vma_iter_free(&vmi);
>  	validate_mm(mm);
>  	return error;
>  }

Can you make sure that the expand_upwards() still functions on parisc?

Thanks,
Liam
..