traversing vma on nommu

Liam R. Howlett Liam.Howlett at oracle.com
Thu Nov 7 06:22:51 PST 2024


* Hajime Tazaki <thehajime at gmail.com> [241107 07:12]:

...

> 
> after adding mt_validate() across various places, I found
> vma_iter_clear() in nommu.c triggers this issue on nommu UML.
> 
> I'm not totally understanding but if I changed the part with
> vma_iter_clear_gfp(), the issue (and validation error reports) are
> disappeared.
> 
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 385b0c15add8..b5c11bbd69de 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -581,7 +581,8 @@ static int delete_vma_from_mm(struct vm_area_struct *vma)
>  	cleanup_vma_from_mm(vma);
>  
>  	/* remove from the MM's tree and list */
> -	vma_iter_clear(&vmi);
> +	vma_iter_clear_gfp(&vmi, vma->vm_start, vma->vm_end, GFP_KERNEL);
> +	mt_validate(&current->mm->mm_mt);
>  	return 0;
>  }
> 
> do you think this is an appropriate fix ?

No.  Something is going wrong in regards to the vma iterator setup.  If
the values are incorrect on the preallocation then you may not have
enough memory to do the store.  You may end up in a situation where the
vma remains in the tree but the vm_file is removed from the interval
tree and that doesn't seem like a good idea.

Can you check vma_iter_addr(vmi) and vma_iter_end(vmi) before and after
the preallocation call?  I would expect them to have the vma start/end
addresses.

Actually, if you can provide the maple state again during this process
then it would be very helpful.

Thanks,
Liam




More information about the maple-tree mailing list