Messages in this thread | | | Subject | Re: [PATCH]: Handling spurious page fault for hugetlb region for 2.6.14-rc4-git5 | From | Rohit Seth <> | Date | Wed, 19 Oct 2005 18:36:47 -0700 |
| |
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
- 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/
| |