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]

Message-Id: <20220413235109.132da02b3c2a883332ada39c@linux-foundation.org>
Date:   Wed, 13 Apr 2022 23:51:09 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Liam Howlett <liam.howlett@...cle.com>,
        Yang Shi <shy828301@...il.com>
Cc:     "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()

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()?


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"?