Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752362AbaBRSx2 (ORCPT ); Tue, 18 Feb 2014 13:53:28 -0500 Received: from mga02.intel.com ([134.134.136.20]:55738 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752314AbaBRSx0 (ORCPT ); Tue, 18 Feb 2014 13:53:26 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,502,1389772800"; d="scan'208";a="485353789" Date: Tue, 18 Feb 2014 13:53:23 -0500 From: Matthew Wilcox To: Linus Torvalds Cc: "Wilcox, Matthew R" , Rik van Riel , "Kirill A. Shutemov" , Andrew Morton , Mel Gorman , Andi Kleen , Dave Hansen , Alexander Viro , Dave Chinner , linux-mm , linux-fsdevel , Linux Kernel Mailing List Subject: Re: [RFC, PATCHv2 0/2] mm: map few pages around fault address if they are in page cache Message-ID: <20140218185323.GB5744@linux.intel.com> References: <1392662333-25470-1-git-send-email-kirill.shutemov@linux.intel.com> <53035FE2.4080300@redhat.com> <100D68C7BA14664A8938383216E40DE04062DEA1@FMSMSX114.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 18, 2014 at 10:02:26AM -0800, Linus Torvalds wrote: > On Tue, Feb 18, 2014 at 6:15 AM, Wilcox, Matthew R > wrote: > > We don't really need to lock all the pages being returned to protect > > against truncate. We only need to lock the one at the highest index, > > and check i_size while that lock is held since truncate_inode_pages_range() > > will block on any page that is locked. > > > > We're still vulnerable to holepunches, but there's no locking currently > > between holepunches and truncate, so we're no worse off now. > > It's not "holepunches and truncate", it's "holepunches and page > mapping", and I do think we currently serialize the two - the whole > "check page->mapping still being non-NULL" before mapping it while > having the page locked does that. Yes, I did mean "holepunches and page faults". But here's the race I see: Process A Process B ext4_fallocate() ext4_punch_hole() filemap_write_and_wait_range() mutex_lock(&inode->i_mutex); truncate_pagecache_range() unmap_mapping_range() __do_fault() filemap_fault() lock_page_or_retry() (page->mapping == mapping at this point) set_pte_at() unlock_page() truncate_inode_pages_range() (now the pte is pointing at a page that is no longer attached to this file) mutex_unlock(&inode->i_mutex); Would we solve the problem by putting in a second call to unmap_mapping_range() after calling truncate_inode_pages_range() in truncate_pagecache_range(), like truncate_pagecache() does? > Besides, that per-page locking should serialize against truncate too. > No, there is no "global" serialization, but there *is* exactly that > page-level serialization where both truncation and hole punching end > up making sure that the page no longer exists in the page cache and > isn't mapped. What I'm suggesting is going back to Kirill's earlier patch, but only locking the page with the highest index instead of all of the pages. truncate() will block on that page and then we'll notice that some or all of the other pages are also now past i_size and give up. -- 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/