linux-kernel - Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150708203456.GC4669@akamai.com>
Date:	Wed, 8 Jul 2015 16:34:56 -0400
From:	Eric B Munson <emunson@...mai.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...e.cz>,
	Vlastimil Babka <vbabka@...e.cz>, linux-alpha@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mips@...ux-mips.org,
	linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
	linux-mm@...ck.org, linux-arch@...r.kernel.org,
	linux-api@...r.kernel.org
Subject: Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock
 flags to enable it

On Wed, 08 Jul 2015, Jonathan Corbet wrote:

> On Tue,  7 Jul 2015 13:03:41 -0400
> Eric B Munson <emunson@...mai.com> wrote:
> 
> > This patch introduces the ability to request that pages are not
> > pre-faulted, but are placed on the unevictable LRU when they are finally
> > faulted in.  This can be done area at a time via the
> > mlock2(MLOCK_ONFAULT) or the mlockall(MCL_ONFAULT) system calls.  These
> > calls can be undone via munlock2(MLOCK_ONFAULT) or
> > munlockall2(MCL_ONFAULT).
> 
> Quick, possibly dumb question: I've been beating my head against these for
> a little bit, and I can't figure out what's supposed to happen in this
> case:
> 
> 	mlock2(addr, len, MLOCK_ONFAULT);
> 	munlock2(addr, len, MLOCK_LOCKED);
> 
> It looks to me like it will clear VM_LOCKED without actually unlocking any
> pages.  Is that the intended result?

This is not quite right, what happens when you call munlock2(addr, len,
MLOCK_LOCKED); is we call apply_vma_flags(addr, len, VM_LOCKED, false).
The false argument means that we intend to clear the specified flags.
Here is the relevant snippet:
...
                newflags = vma->vm_flags;
                if (add_flags) {
                        newflags &= ~(VM_LOCKED | VM_LOCKONFAULT);
                        newflags |= flags;
                } else {
                        newflags &= ~flags;
                }
...

Note that when we are adding flags, we first clear both VM_LOCKED and
VM_LOCKONFAULT.  This was done to match the behavior found in
mlockall().  When we are remove flags, we simply clear the specified
flag(s).

So in your example the state of the VMAs covered by addr and len would
remain unchanged.

It sounds like apply_vma_flags() needs a comment covering this topic, I
will include that in the set I am working on now.

Eric

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)