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:   Thu, 12 Oct 2017 16:34:22 +0530
From:   Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Cc:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Michal Nazarewicz <mina86@...a86.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Guy Shattah <sguy@...lanox.com>,
        Christoph Lameter <cl@...ux.com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        Laura Abbott <labbott@...hat.com>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [RFC PATCH 2/3] mm/map_contig: Use pre-allocated pages for
 VM_CONTIG mappings

On 10/12/2017 07:16 AM, Mike Kravetz wrote:
> When populating mappings backed by contiguous memory allocations
> (VM_CONTIG), use the preallocated pages instead of allocating new.
> 
> Signed-off-by: Mike Kravetz <mike.kravetz@...cle.com>
> ---
>  mm/memory.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index a728bed16c20..fbef78d07cf3 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3100,7 +3100,18 @@ static int do_anonymous_page(struct vm_fault *vmf)
>  	/* Allocate our own private page. */
>  	if (unlikely(anon_vma_prepare(vma)))
>  		goto oom;
> -	page = alloc_zeroed_user_highpage_movable(vma, vmf->address);
> +
> +	/*
> +	 * In the special VM_CONTIG case, pages have been pre-allocated. So,
> +	 * simply grab the appropriate pre-allocated page.
> +	 */
> +	if (unlikely(vma->vm_flags & VM_CONTIG)) {
> +		VM_BUG_ON(!vma->vm_private_data);
> +		page = ((struct page *)vma->vm_private_data) +
> +			((vmf->address - vma->vm_start) / PAGE_SIZE);
> +	} else {
> +		page = alloc_zeroed_user_highpage_movable(vma, vmf->address);

vm_private_data should be fine. Seems like its getting used for HugeTLB,
special mappings and for shared memory as well. As long as we dont cross
these things (lets say while enabling this for file mapping etc with
MAP_CONTIG), we can keep using vm_private_data.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ