Re: [PATCH]: Handling spurious page fault for hugetlb region for 2.6.14-rc4-git5

[Rohit Seth <rohit.seth@intel.com>]

On Wed, 2005-10-19 at 21:28 +0100, Hugh Dickins wrote:
> On Wed, 19 Oct 2005, Andrew Morton wrote:
> > Hugh Dickins <hugh@veritas.com> wrote:
> > > 
> > >  I was forgetting that extending ftruncate wasn't supported in 2.6.14 and
> > >  earlier, yes.  But I'm afraid the above scenario can still happen there:
> > >  extending is done, not by ftruncate, but by (somewhere else) mmapping the
> > >  larger size.   So your fix may still cause a tight infinite fault loop.
> > 
> > Will it?  Whenever we mmap a hugetlbfs file we prepopulate the entire vma
> > with hugepages.  So I don't think there's ever any part of an address space
> > which ia a) inside a hugepage vma and b) doesn't have a hugepage backing
> > it.
> 
> The new vma, sure, will be fully populated.  But the old vma, in this
> or some other process, which was created before the hugetlbfs file was
> truncated down, will be left with a hole at the end.
> 

Excellent catch.  This broken truncation thing....

And I don't know what the right solution should be for this scenario at
this point for 2.6.14....may be to actually look at the HUGEPTE
corresponding to the hugetlb faulting address or don't allow mmaps to
grow the hugetlb file bigger (except the first mmap).  I understand that
both of them don't sound too good...

Any suggestions.

-rohit