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 16:53 -0700, Rohit Seth wrote:
> 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.
> 


I would like to keep this patch.  This at least takes care of bad things
happening behind application's back by OS/HW.  If the scenario that you
mentioned happens then the application is knowingly doing unsupported
things (at this point truncate is a broken operation on hugetlb).  The
application can be killed in this case.

...trying to avoid any heavy changes at this time for 2.6.14

-rohit