linux-kernel - Re: [PATCH] hugetlb: avoid gratuitous BUG_ON in hugetlb_fault() -> hugetlb

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: <alpine.LSU.2.00.1204301308090.2829@eggly.anvils>
Date:	Mon, 30 Apr 2012 13:19:27 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Chris Metcalf <cmetcalf@...era.com>, Mel Gorman <mel@....ul.ie>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Hillf Danton <dhillf@...il.com>, Michal Hocko <mhocko@...e.cz>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hugetlb: avoid gratuitous BUG_ON in hugetlb_fault() ->
 hugetlb_cow()

On Sun, 29 Apr 2012, Chris Metcalf wrote:

> Commit 66aebce747eaf added code to avoid a race condition by
> elevating the page refcount in hugetlb_fault() while calling
> hugetlb_cow().  However, one code path in hugetlb_cow() includes
> an assertion that the page count is 1, whereas it may now also
> have the value 2 in this path.
> 
> Signed-off-by: Chris Metcalf <cmetcalf@...era.com>
> ---
> We discovered this while testing the original path; one particular
> application triggered this due to the specific number of huge pages
> it started with.

Well done finding that.  But I think it would be better to remove the
BUG_ON() than complicate it, and then no need to add a comment there.

IIRC it's unsafe to make any assertions about what a page_count() may
be, beyond whether it's 0 or non-0: because of speculative accesses to
the page from elsewhere (perhaps it used to be visible in a radix_tree,
perhaps __isolate_lru_pages is having a go at it).

I'd say that BUG_ON() has outlived its usefulness, and should just be
eliminated now: but git "blames" Mel for it, so let's see if he agrees.

Hugh

> 
>  mm/hugetlb.c |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cd65cb1..d5b0254 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2498,7 +2498,14 @@ retry_avoidcopy:
>  		if (outside_reserve) {
>  			BUG_ON(huge_pte_none(pte));
>  			if (unmap_ref_private(mm, vma, old_page, address)) {
> -				BUG_ON(page_count(old_page) != 1);
> +				/*
> +				 * Page refcount may be 1 in the common case,
> +				 * but since we may do an extra get_page()
> +				 * when called from hugetlb_fault(), we allow
> +				 * a page refcount of 2 as well.
> +				 */
> +				BUG_ON(page_count(old_page) != 1 &&
> +				       page_count(old_page) != 2);
>  				BUG_ON(huge_pte_none(pte));
>  				spin_lock(&mm->page_table_lock);
>  				ptep = huge_pte_offset(mm, address & huge_page_mask(h));
> -- 
> 1.6.5.2
--
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/