linux-kernel - Re: [rfc 5/5] mincore: transparent huge page support

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: <20100324224858.GP10659@random.random>
Date:	Wed, 24 Mar 2010 23:48:58 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [rfc 5/5] mincore: transparent huge page support

On Tue, Mar 23, 2010 at 03:35:02PM +0100, Johannes Weiner wrote:
> +static int mincore_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
> +			unsigned long addr, unsigned long end,
> +			unsigned char *vec)
> +{
> +	int huge = 0;
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +	spin_lock(&vma->vm_mm->page_table_lock);
> +	if (likely(pmd_trans_huge(*pmd))) {
> +		huge = !pmd_trans_splitting(*pmd);

Under mmap_sem (read or write) a hugepage can't materialize under
us. So here the pmd_trans_huge can be lockless and run _before_ taking
the page_table_lock. That's the invariant I used to keep identical
performance for all fast paths.

And if it wasn't the case it wouldn't be safe to return huge = 0 as
the page_table_lock is released at that point.

> +		spin_unlock(&vma->vm_mm->page_table_lock);
> +		/*
> +		 * If we have an intact huge pmd entry, all pages in
> +		 * the range are present in the mincore() sense of
> +		 * things.
> +		 *
> +		 * But if the entry is currently being split into
> +		 * normal page mappings, wait for it to finish and
> +		 * signal the fallback to ptes.
> +		 */
> +		if (huge)
> +			memset(vec, 1, (end - addr) >> PAGE_SHIFT);
> +		else
> +			wait_split_huge_page(vma->anon_vma, pmd);
> +	} else
> +		spin_unlock(&vma->vm_mm->page_table_lock);
> +#endif
> +	return huge;
> +}
> +

It's probably cleaner to move the block into huge_memory.c and create
a dummy for the #ifndef version like I did for all the rest.


I'll incorporate and take care of those changes myself if you don't
mind, as I'm going to do a new submit for -mm. I greatly appreciated
you taken the time to port to transhuge it helps a lot! ;)

Thanks,
Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/