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

Date:	Tue, 29 Nov 2011 13:00:32 -0500
From:	Youquan Song <youquan.song@...el.com>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Youquan Song <youquan.song@...el.com>,
	linux-kernel@...r.kernel.org, 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

> > > 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.

I notice 70b50f94f1644e2aa7cb374819cfd93f3c28d725 "mm: thp: tail page
refcounting fix" is in kernel 3.1.1 stable, so this series patches can be also
applied to 3.1 stable. 

I expect the patch 70b50f94f1644e2aa7cb374819cfd93f3c28d725 also go to
3.0 stable, so this series patches also applied to 3.0 stable.
 
Thanks
-Youquan
--
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/