linux-kernel - Re: [PATCH 1/2] thp: Add compound tail page

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:	Tue, 29 Nov 2011 01:58:39 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Youquan Song <youquan.song@...el.com>,
	linux-kernel@...r.kernel.org, wli@...omorphy.com,
	david.woodhouse@...el.com, allen.m.kay@...el.com,
	mtosatti@...hat.com, chrisw@...hat.com, chaohong.guo@...el.com,
	Youquan Song <youquan.song@...ux.intel.com>
Subject: Re: [PATCH 1/2] thp: Add compound tail page _mapcount when mapped

On Tue, Nov 29, 2011 at 01:19:27AM +0100, Andi Kleen wrote:
> > > +++ b/arch/x86/mm/gup.c
> > > @@ -201,6 +201,8 @@ static noinline int gup_huge_pud(pud_t pud, unsigned long addr,
> > >  	do {
> > >  		VM_BUG_ON(compound_head(page) != head);
> > >  		pages[*nr] = page;
> > > +		if (PageTail(page))
> > > +			get_huge_page_tail(page);
> > >  		(*nr)++;
> > >  		page++;
> > >  		refs++;
> > 
> > Is the patch also applicable to 3.1.x?
> 
> I suspect it's broken since many kernels back, at least since THP 
> was introduced, maybe earlier.

Correct. And the other patch in this series if applied without the
above too, would make things worse for earlier releases (it'd trigger
the lack of above at first invocation instead of from the second by
having the _count start at 0 instead of 1, so it'd go negative at the
first put_page). The correct thing is to have _count start at 0, but
to increase it with the above during gup_fast (or to increase
_mapcount since 3.2-rc and leave _count at 0 at all times on tail
pages). Both patches should be ok for earlier releases too but I think
it's just a false positive that goes away with DEBUG_VM=n or we should
have noticed sooner (all production systems runs with DEBUG_VM=n of
course). If there is no problem with DEBUG_VM=n like it seems from the
source, I doubt it needs backporting. Also worst case a VM_BUG_ON
hits, there's no risk of memory corruption because the refcounting on
the head pages has always been correct, and that's all it matters
as far as hugetlbfs is concerned.
--
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/