linux-kernel - Re: [RFC] Tracking mlocked pages and moving them off the LRU

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]

Date:	Sat, 03 Feb 2007 19:04:20 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	Christoph Lameter <clameter@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [RFC] Tracking mlocked pages and moving them off the LRU

On Sat, 2007-02-03 at 09:56 -0800, Christoph Lameter wrote:
> On Sat, 3 Feb 2007, Andrew Morton wrote:
> 
> > I wonder if it can be simpler.  Make two changes:
> 
> Would be great if this could get simpler.
> 
> > a) If the scanner encounters an mlocked page on the LRU, take it off.
> 
> The current patch takes them off when mlock is set (which may not work 
> since the page may be off the LRU) and then has the scanner taking them 
> off. We could just remove the early one but what would this bring us?

it's simpler. You only move them off when you encounter them during a
scan. No walking early etc etc. Only do work when there is an actual
situation where you do scan.

> 
> > b) munlock() adds all affected pages to the LRU.
> 
> Hmmm... You mean without checking all the vmas of a page for VM_LOCKED? So they 
> are going to be removed again on the next pass? Ok. I see that makes it 
> simpler but it requires another reclaim scan.

Well.. That's the point! Only IF there is a reclaim scan do you move
them out again. The fact that these pages are on the list isn't a
problem. The fact that you keep encountering them over and over again
during *scanning* is. So Andrews suggestion makes them go away in the
situations that actually matter

> The page flag allows a clean state transition of a page and accurate 
> keeping of statistics for MLOCKed pages. There were objections against the 
> fuzzy counting in the earlier incarnation and it was proposed that a page 
> flag be introduced. Without the flag we cannot know that the page is 
> already mapped by a VM_LOCKED vma without scanning over all vmas 
> referencing the page.

who cares though.. just do it lazy.


-
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/