From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45483C37.6040303@yahoo.com.au> Date: Wed, 01 Nov 2006 17:18:31 +1100 From: Nick Piggin MIME-Version: 1.0 Subject: Re: [RFC] reduce hugetlb_instantiation_mutex usage References: <20061031031703.GA7220@localhost.localdomain> <000001c6fcab$8fe56320$5181030a@amr.corp.intel.com> <20061031110540.GA14172@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Hugh Dickins Cc: 'David Gibson' , "Chen, Kenneth W" , g@ozlabs.org, Andrew Morton , 'Christoph Lameter' , bill.irwin@oracle.com, Adam Litke , linux-mm@kvack.org List-ID: 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: email@kvack.org