From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: Dirty/Access bits vs. page content Date: Fri, 25 Apr 2014 09:54:46 -0700 Message-ID: <535A9356.8060608@intel.com> References: <53558507.9050703@zytor.com> <20140422075459.GD11182@twins.programming.kicks-ass.net> <20140423184145.GH17824@quack.suse.cz> <20140424065133.GX26782@laptop.programming.kicks-ass.net> <1398389846.8437.6.camel@pasglop> <1398393700.8437.22.camel@pasglop> <5359CD7C.5020604@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org To: Hugh Dickins , Linus Torvalds Cc: "H. Peter Anvin" , Benjamin Herrenschmidt , Peter Zijlstra , Jan Kara , "linux-arch@vger.kernel.org" , linux-mm , Russell King - ARM Linux , Tony Luck List-Id: linux-arch.vger.kernel.org On 04/25/2014 05:01 AM, Hugh Dickins wrote: > Er, i_mmap_mutex. > > That's what unmap_mapping_range(), and page_mkclean()'s rmap_walk, > take to iterate over the file vmas. So perhaps there's no race at all > in the unmap_mapping_range() case. And easy (I imagine) to fix the > race in Dave's racewrite.c use of MADV_DONTNEED: untested patch below. > > But exit and munmap() don't take i_mmap_mutex: perhaps they should > when encountering a VM_SHARED vma (I believe VM_SHARED should be > peculiar to having vm_file set, but test both below because I don't > want to oops in some odd corner where a special vma is set up). Hey Hugh, Do you want some testing on this? -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com ([134.134.136.24]:11490 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751297AbaDYQyr (ORCPT ); Fri, 25 Apr 2014 12:54:47 -0400 Message-ID: <535A9356.8060608@intel.com> Date: Fri, 25 Apr 2014 09:54:46 -0700 From: Dave Hansen MIME-Version: 1.0 Subject: Re: Dirty/Access bits vs. page content References: <53558507.9050703@zytor.com> <20140422075459.GD11182@twins.programming.kicks-ass.net> <20140423184145.GH17824@quack.suse.cz> <20140424065133.GX26782@laptop.programming.kicks-ass.net> <1398389846.8437.6.camel@pasglop> <1398393700.8437.22.camel@pasglop> <5359CD7C.5020604@zytor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Hugh Dickins , Linus Torvalds Cc: "H. Peter Anvin" , Benjamin Herrenschmidt , Peter Zijlstra , Jan Kara , "linux-arch@vger.kernel.org" , linux-mm , Russell King - ARM Linux , Tony Luck Message-ID: <20140425165446.mGoY5-M0GsidQNMlBwAI_R25O5TR22AQPvLbKsxe-D4@z> On 04/25/2014 05:01 AM, Hugh Dickins wrote: > Er, i_mmap_mutex. > > That's what unmap_mapping_range(), and page_mkclean()'s rmap_walk, > take to iterate over the file vmas. So perhaps there's no race at all > in the unmap_mapping_range() case. And easy (I imagine) to fix the > race in Dave's racewrite.c use of MADV_DONTNEED: untested patch below. > > But exit and munmap() don't take i_mmap_mutex: perhaps they should > when encountering a VM_SHARED vma (I believe VM_SHARED should be > peculiar to having vm_file set, but test both below because I don't > want to oops in some odd corner where a special vma is set up). Hey Hugh, Do you want some testing on this?