mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: Rik van Riel <riel@redhat.com>, Andrew Morton <akpm@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: 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)
Date: Wed, 21 Sep 2005 17:50:05 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.61.0509211729020.8121@goblin.wat.veritas.com> (raw)
In-Reply-To: <200509211816.37512.blaisorblade@yahoo.it>

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

  reply	other threads:[~2005-09-21 16:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-26 18:23 [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3 Blaisorblade
2005-08-26 19:11 ` Hugh Dickins
2005-08-26 19:58   ` [uml-devel] " Blaisorblade
2005-09-02 21:02 ` Hugh Dickins
2005-09-04 19:10   ` [uml-devel] " Blaisorblade
2005-09-07 12:00     ` Hugh Dickins
2005-09-13 18:25       ` Blaisorblade
2005-09-20 15:06       ` 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) Blaisorblade
2005-09-20 18:23         ` Rik van Riel
2005-09-21 15:16         ` Hugh Dickins
2005-09-21 16:16           ` Blaisorblade
2005-09-21 16:50             ` Hugh Dickins [this message]
2005-09-21 17:02               ` Blaisorblade
2005-09-26 15:58       ` [uml-devel] Re: [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3 Blaisorblade
2005-09-28 13:37         ` Hugh Dickins
2005-09-28 16:20           ` Blaisorblade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0509211729020.8121@goblin.wat.veritas.com \
    --to=hugh@veritas.com \
    --cc=akpm@osdl.org \
    --cc=blaisorblade@yahoo.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®