Messages in this thread | | | Date | Wed, 19 Oct 2005 18:37:48 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH]: Handling spurious page fault for hugetlb region for 2.6.14-rc4-git5 |
| |
Rohit Seth <rohit.seth@intel.com> wrote: > > > 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.
Yes, we had an infinite-page-fault bug in the vmalloc code ages ago and the app was indeed killable. It'd be nice to confirm that this is still the case. If so, the stopgap approach seems reasonable.
As long as the demand-paging patches get in, that is. - 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/
| |