Re: Remap_file_pages, RSS limits, security implications (was: Re: [uml-devel] Re: [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3)

[Hugh Dickins <hugh@veritas.com>]

On Wed, 21 Sep 2005, Blaisorblade wrote:
> 
> Other pages in the VMA may be unmapped, yes, but not freed. In fact, they're 
> kept in by the pagecache reference; try_to_unmap() (or better its caller, 
> shrink_list) will only actually free the page it asked for.

Not freed in that pass, yes; but brought closer to being freed soon.

> The only real "problem" is that we do ptep_clear_flush_young without 
> activating the page. And yes, *this* may penalize who holds a nonlinear VMA. 
> But this is probably fair, given that we're going to have trouble in freeing 
> those pages.

Good point, I don't remember ever considering that.
But agree it should work out fairly.

> > mm/trash.c?  I got quite excited,
> What would that have meant?

Trash is rubbish or garbage.  Or if I trash my hotel room (not me!),
I'd rip the washbasin off the wall, smash the mirror, throw the
chair through the window, ... hmm, better stop this public fantasy.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/