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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Rohit Seth <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux