Re: [PATCH 1/2] thp: Add compound tail page _mapcount when mapped

[Youquan Song <youquan.song@intel.com>]

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