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

[Andrew Morton <akpm@osdl.org>]

Hugh Dickins <hugh@veritas.com> wrote:
>
>  On Wed, 19 Oct 2005, Rohit Seth wrote:
>  > On Wed, 2005-10-19 at 16:48 +0100, Hugh Dickins wrote:
>  > > 
>  > > What happens when the hugetlb file is truncated down and back up after
>  > > the mmap?  Truncating down will remove a page from the mmap and flush TLB.
>  > > Truncating up will let accesses to the gone page pass the valid...off test.
>  > > But we've no support for hugetlb faulting in this version: so won't it get
>  > > get stuck in a tight loop?
>  > 
>  > First of all, there is currently no support of extending the hugetlb
>  > file size using truncate in 2.6.14. (I agree that part is broken).  So
>  > the above scenario can not happen.
> 
>  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.