[lkml]   [2011]   [Nov]   [29]   [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
> > > 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.


 \ /
  Last update: 2011-11-29 06:39    [W:0.062 / U:0.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site