Re: [RFC] reduce hugetlb_instantiation_mutex usage

[Nick Piggin <nickpiggin@yahoo.com.au>]

Hugh Dickins wrote:
> On Tue, 31 Oct 2006, 'David Gibson' wrote:
> 
>>On Mon, Oct 30, 2006 at 09:15:20PM -0800, Chen, Kenneth W wrote:
>>
>>>Instead, I'm asking how private mapping protect race between file truncation
>>>and fault? For shared mapping, it is clear to me that we are using lock_page
>>>to protect file truncate with fault.  But I don't see that protection with
>>>private mapping in current upstream kernel.
>>
>>Oh, ok.  I can't see how it matters in the PRIVATE case, given that
>>truncate() won't, and shouldn't, truncate privately mapped pages.
> 
> 
> Bzzt, it does and should (unless we decide to make hugetlbfs pages diverge
> from the standard for ordinary pages in this respect - could do, but that
> would require thought of its own).  If you've been thinking otherwise,
> that may explain why some of the accounting goes wrong.

So what does the normal page fault path do? Just invalidates the private
page out of the page tables. A subsequent fault goes through the normal
shared page path, which detects the truncation as it would with any
shared fault. Right?

hugetlb seems to pretty well follow the same pattern as memory.c in this
regard. I don't see the race?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>