linux-kernel - Re: [PATCH v7 26/70] mm/mmap: Use advanced maple tree API for mmap

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Apr 2022 17:57:46 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
CC:     Yang Shi <shy828301@...il.com>,
        "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 26/70] mm/mmap: Use advanced maple tree API for
 mmap_region()

* Andrew Morton <akpm@...ux-foundation.org> [220414 02:51]:
> On Mon, 4 Apr 2022 14:35:43 +0000 Liam Howlett <liam.howlett@...cle.com> wrote:
> 
> > From: "Liam R. Howlett" <Liam.Howlett@...cle.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?