linux-kernel - Re: [RFC] Track mlock()ed pages

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] [day] [month] [year] [list]

Message-ID: <45BBD3D1.60605@redhat.com>
Date:	Sat, 27 Jan 2007 17:36:01 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Andrew Morton <akpm@...l.org>
CC:	Christoph Lameter <clameter@....com>,
	Nick Piggin <nickpiggin@...oo.com.au>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Track mlock()ed pages

Andrew Morton wrote:
> On Sat, 27 Jan 2007 17:19:21 -0500
> Rik van Riel <riel@...hat.com> wrote:
> 
>> Andrew Morton wrote:
>>
>>> Of course it would.  But how do you know it is "too expensive"?  We "scan
>>> all the vmas mapping a page" as a matter of course in the page scanner -
>>> millions of times a minute.  If that's "too expensive" then ouch.
>> We can do it lazily.
>>
>> At mlock time, move pages onto the mlocked list, unless they
>> are there already.
> 
> Needs another page flag to determine what list the page is on (eek).
> 
>> On munlock, move pages to the active list.
> 
> We'd need to determine whether some other vma has mlocked the page too. 
> That's either the page_struct refcount or the vma walk.  The latter is
> equivalent to what I'm suggesting.

It doesn't have to be 100% accurate.  The pages that are mapped
both mlocked and non-mlocked will probably be only shared
libraries.

>>  For mlock-only
>> memory (shared memory segments?) we could add a simple check
>> to see if the next process on the list has the page mlocked,
>> checking only that one.

As long as we get it right for the large objects, it should be
fine.

> I'm still not sure what problem we're trying to solve here.
> 
> Knowing how many mlocked pages there are in a zone doesn't sound terribly
> interesting and I don't recall ever wanting to know that.
> 
> Being able to keep mlocked pages off the LRU altogether sounds more useful.

> It's all rather a tight corner case - people don't use mlock much.

Just because it's not common does not mean you can just ignore
it and hope Linux doesn't unexpectedly fall over.

One thing that knowing the amount of mlocked data in each zone
(and node) would allow us to do is spread the mlocked memory
around a little better at allocation time.  This could prevent
some of the "I started a 6GB Oracle on my 8GB system and it
immediately fell over" bugs.

-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/