Messages in this thread | | | Date | Wed, 19 Oct 2005 13:19:07 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH]: Handling spurious page fault for hugetlb region for 2.6.14-rc4-git5 |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |