Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Newsgroups: linux.kernel
Subject: Re: [PATCH 2/4] mm: mlock: avoid increase mm->locked_vm on mlock()  when already mlock2(,MLOCK_ONFAULT)
Date: Tue, 30 Aug 2016 13:40:01 +0200
Message-ID: <sbPyx-4bb-13@gated-at.bofh.it>
References: <sbP5v-41d-7@gated-at.bofh.it> <sbP5w-41d-13@gated-at.bofh.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: robomod@news.nic.it
Approved: robomod@news.nic.it
Lines: 26
Organization: linux.* mail to news gateway
Xref: csiph.com linux.kernel:1472427

On Tue, Aug 30, 2016 at 06:59:39PM +0800, wei.guo.simon@gmail.com wrote:
> From: Simon Guo <wei.guo.simon@gmail.com>
> 
> When one vma was with flag VM_LOCKED|VM_LOCKONFAULT (by invoking
> mlock2(,MLOCK_ONFAULT)), it can again be populated with mlock() with
> VM_LOCKED flag only.
> 
> There is a hole in mlock_fixup() which increase mm->locked_vm twice even
> the two operations are on the same vma and both with VM_LOCKED flags.
> 
> The issue can be reproduced by following code:
> mlock2(p, 1024 * 64, MLOCK_ONFAULT); //VM_LOCKED|VM_LOCKONFAULT
> mlock(p, 1024 * 64);  //VM_LOCKED
> Then check the increase VmLck field in /proc/pid/status(to 128k).
> 
> When vma is set with different vm_flags, and the new vm_flags is with
> VM_LOCKED, it is not necessarily be a "new locked" vma.  This patch
> corrects this bug by prevent mm->locked_vm from increment when old
> vm_flags is already VM_LOCKED.
> 
> Signed-off-by: Simon Guo <wei.guo.simon@gmail.com>

Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov