From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by kanga.kvack.org (Postfix) with ESMTP id 320986B0087 for ; Thu, 23 Oct 2014 11:05:52 -0400 (EDT) Received: by mail-wi0-f177.google.com with SMTP id ex7so2087928wid.16 for ; Thu, 23 Oct 2014 08:05:51 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi. [62.71.2.194]) by mx.google.com with ESMTP id fq9si5313529wib.81.2014.10.23.08.05.50 for ; Thu, 23 Oct 2014 08:05:50 -0700 (PDT) Date: Thu, 23 Oct 2014 18:05:08 +0300 From: "Kirill A. Shutemov" Subject: Re: [RFC][PATCH 3/6] mm: VMA sequence count Message-ID: <20141023150508.GA10316@node.dhcp.inet.fi> References: <20141020215633.717315139@infradead.org> <20141020222841.361741939@infradead.org> <20141022112657.GG30588@node.dhcp.inet.fi> <20141022113951.GB21513@worktop.programming.kicks-ass.net> <20141022115304.GA31486@node.dhcp.inet.fi> <20141022121554.GD21513@worktop.programming.kicks-ass.net> <20141022134416.GA15602@worktop.programming.kicks-ass.net> <20141023123616.GA8809@node.dhcp.inet.fi> <20141023142224.GL3219@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141023142224.GL3219@twins.programming.kicks-ass.net> Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: torvalds@linux-foundation.org, paulmck@linux.vnet.ibm.com, tglx@linutronix.de, akpm@linux-foundation.org, riel@redhat.com, mgorman@suse.de, oleg@redhat.com, mingo@redhat.com, minchan@kernel.org, kamezawa.hiroyu@jp.fujitsu.com, viro@zeniv.linux.org.uk, laijs@cn.fujitsu.com, dave@stgolabs.net, linux-kernel@vger.kernel.org, linux-mm@kvack.org On Thu, Oct 23, 2014 at 04:22:24PM +0200, Peter Zijlstra wrote: > On Thu, Oct 23, 2014 at 03:36:16PM +0300, Kirill A. Shutemov wrote: > > On Wed, Oct 22, 2014 at 03:44:16PM +0200, Peter Zijlstra wrote: > > > On Wed, Oct 22, 2014 at 02:15:54PM +0200, Peter Zijlstra wrote: > > > > On Wed, Oct 22, 2014 at 02:53:04PM +0300, Kirill A. Shutemov wrote: > > > > > Em, no. In this case change_protection() will not touch the pte, since > > > > > it's pte_none() and the pte_same() check will pass just fine. > > > > > > > > Oh, that's what you meant. Yes that's a problem, yes vm_page_prot > > > > needs wrapping too. > > > > > > Maybe also vm_policy, is there anything else that can change while a vma > > > lives? > > > > - vm_flags, obviously; > > Do those ever change? The flags which can change (probably incomplete): - prot-related: VM_READ, VM_WRITE, VM_EXEC -- mprotect(); - VM_LOCKED - mlock(); - VM_SEQ_READ, VM_RAND_READ, VM_DONTCOPY, VM_DONTDUMP, VM_HUGEPAGE, VM_NOHUGEPAGE, VM_MERGEABLE -- madvise(); - VM_SOFTDIRTY -- through procfs; > The only thing that jumps out is the VM_LOCKED thing and that should not > really matter one way or the other, but sure can do. I would not be that sure about VM_LOCKED. Consider munlock() vs. write fault race. static int do_wp_page(struct fault_env *fe) __releases(ptl) { ... err: if (old_page) { /* * Don't let another task, with possibly unlocked vma, * keep the mlocked page. */ if ((ret & VM_FAULT_WRITE) && (fe->vma->vm_flags & VM_LOCKED)) { lock_page(old_page); /* LRU manipulation */ munlock_vma_page(old_page); unlock_page(old_page); } page_cache_release(old_page); } return ret; ... } The page can leak out mlocked, iiuc. Some other flags can be problematic too. > In any case, yes I'll go include them. I hope it will not hurt single-threaded workloads even more. :-/ -- Kirill A. Shutemov -- 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