[lkml]   [2011]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.

     \ /
      Last update: 2011-11-29 02:05    [W:0.032 / U:20.028 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site