Re: [PATCH v7 26/70] mm/mmap: Use advanced maple tree API for mmap_region()

[Liam Howlett <liam.howlett@oracle.com>]

* Andrew Morton <akpm@linux-foundation.org> [220414 02:51]:
> On Mon, 4 Apr 2022 14:35:43 +0000 Liam Howlett <liam.howlett@oracle.com> wrote:
> 
> > From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
> > 
> > Changing mmap_region() to use the maple tree state and the advanced
> > maple tree interface allows for a lot less tree walking.
> > 
> > This change removes the last caller of munmap_vma_range(), so drop this
> > unused function.
> > 
> > Add vma_expand() to expand a VMA if possible by doing the necessary
> > hugepage check, uprobe_munmap of files, dcache flush, modifications then
> > undoing the detaches, etc.
> > 
> 
> Merging this with Yang Shi's "mm: mmap: register suitable readonly file
> vmas for khugepaged"
> (https://lkml.kernel.org/r/20220404200250.321455-9-shy828301@gmail.com)
> 
> > ...
> >
> > @@ -1741,13 +1868,28 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> >  			goto free_vma;
> >  	}
> >  
> > -	vma_link(mm, vma, prev);
> > +	if (vma->vm_file)
> > +		i_mmap_lock_write(vma->vm_file->f_mapping);
> > +
> > +	vma_mas_store(vma, &mas);
> > +	__vma_link_list(mm, vma, prev);
> > +	mm->map_count++;
> > +	if (vma->vm_file) {
> > +		if (vma->vm_flags & VM_SHARED)
> > +			mapping_allow_writable(vma->vm_file->f_mapping);
> > +
> > +		flush_dcache_mmap_lock(vma->vm_file->f_mapping);
> > +		vma_interval_tree_insert(vma, &vma->vm_file->f_mapping->i_mmap);
> > +		flush_dcache_mmap_unlock(vma->vm_file->f_mapping);
> > +		i_mmap_unlock_write(vma->vm_file->f_mapping);
> > +	}
> > +
> >  	/* Once vma denies write, undo our temporary denial count */
> >  unmap_writable:
> >  	if (file && vm_flags & VM_SHARED)
> >  		mapping_unmap_writable(file->f_mapping);
> 
> I'm unsure whether this hunk should be inside or outside the call to
> the cheerfully undocumented khugepaged_enter_vma()?

Below.  I've replaced the vma_link() with a write to the tree and
inlined the handling of vm_file.  At least, it will keep with what Yang
Shi wrote in the patch you are merging.

> 
> 
> Code snippet as I presently have it:
> 
> 	if (vma->vm_file)
> 		i_mmap_lock_write(vma->vm_file->f_mapping);
> 
> 	vma_mas_store(vma, &mas);
> 	mm->map_count++;
> 	if (vma->vm_file) {
> 		if (vma->vm_flags & VM_SHARED)
> 			mapping_allow_writable(vma->vm_file->f_mapping);
> 
> 		flush_dcache_mmap_lock(vma->vm_file->f_mapping);
> 		vma_interval_tree_insert(vma, &vma->vm_file->f_mapping->i_mmap);
> 		flush_dcache_mmap_unlock(vma->vm_file->f_mapping);
> 		i_mmap_unlock_write(vma->vm_file->f_mapping);
> 	}
> 
> 	/*
> 	 * vma_merge() calls khugepaged_enter_vma() either, the below
> 	 * call covers the non-merge case.
> 	 */
> 	khugepaged_enter_vma(vma, vma->vm_flags);
> 
> 	/* Once vma denies write, undo our temporary denial count */
> unmap_writable:
> 	if (file && vm_flags & VM_SHARED)
> 		mapping_unmap_writable(file->f_mapping);
> 
> btw, "vma_merge() calls khugepaged_enter_vma() either" isn't
> understandable.  Should that be "also"?

It looks like it should be "also" to me.. Yang Shi?