linux-kernel - Re: [patch -mm] mm, thp: fix mlock statistics fix

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

Message-ID: <alpine.LSU.2.00.1210031430190.14479@eggly.anvils>
Date:	Wed, 3 Oct 2012 14:46:59 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	David Rientjes <rientjes@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Michel Lespinasse <walken@...gle.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch -mm] mm, thp: fix mlock statistics fix

On Wed, 3 Oct 2012, Andrew Morton wrote:
> On Wed, 3 Oct 2012 14:10:41 -0700 (PDT)
> David Rientjes <rientjes@...gle.com> wrote:
> 
> > > The free_page_mlock() hunk gets dropped because free_page_mlock() is
> > > removed.  And clear_page_mlock() doesn't need this treatment.  But
> > > please check my handiwork.
> > > 
> > 
> > I reviewed what was merged into -mm and clear_page_mlock() does need this 
> > fix as well.
> 
> argh, it got me *again*.  grr.

I've no objection to more documentation on PageHuge, but neither you nor
it were to blame for that "oversight".  It's simply that David's original
patch clearly did not need such a change in clear_page_mlock(), because
it could never be necessary from where it was then called; but I changed
where it's called, whereupon it becomes evident that the extra is needed.

"evident" puts it rather too strongly.  Most munlocking happens through
munlock_vma_page() instead, but the clear_page_mlock() path covers
truncation.  THPages cannot be file pages at present, but perhaps they
could be anonymous pages COWed from file pages (I've not checked the
exact criteria THP applies)?  In which case, subject to truncation too.

Hugh

> 
> From: Andrew Morton <akpm@...ux-foundation.org>
> Subject: mm: document PageHuge somewhat
> 
> Cc: David Rientjes <rientjes@...gle.com>
> Cc: Mel Gorman <mel@....ul.ie>
> Cc: Andrea Arcangeli <aarcange@...hat.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> ---
> 
>  mm/hugetlb.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff -puN mm/hugetlb.c~mm-document-pagehuge-somewhat mm/hugetlb.c
> --- a/mm/hugetlb.c~mm-document-pagehuge-somewhat
> +++ a/mm/hugetlb.c
> @@ -671,6 +671,11 @@ static void prep_compound_gigantic_page(
>  	}
>  }
>  
> +/*
> + * PageHuge() only returns true for hugetlbfs pages, but not for normal or
> + * transparent huge pages.  See the PageTransHuge() documentation for more
> + * details.
> + */
>  int PageHuge(struct page *page)
>  {
>  	compound_page_dtor *dtor;
> _
--
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/