linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Hugh Dickins <hugh@veritas.com>
Cc: linux-mm@kvack.org, Rohit Seth <rohitseth@google.com>,
	David Howells <dhowells@redhat.com>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Christoph Lameter <clameter@sgi.com>
Subject: Re: tracking dirty pages patches
Date: Wed, 24 May 2006 04:25:14 +0200	[thread overview]
Message-ID: <1148437514.3049.18.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0605232131560.19019@blonde.wat.veritas.com>

On Tue, 2006-05-23 at 21:34 +0100, Hugh Dickins wrote:
> > 
> > Page migration currently also assumes that VM_LOCKED means do not move the 
> > page. At some point we may want to have a separate flag that guarantees
> > that a page should not be moved. This would enable the moving of VM_LOCKED 
> > pages.
> 
> Oh yes, I'd noticed that subject going by, and meant to speak up
> sometime.  I feel pretty strongly, and have so declared in the past,
> that VM_LOCKED should _not_ guarantee that the same physical page is
> used forever: get_user_pages is what's used to pin a physical page
> for that effect.  I remember Arjan sharing this opinion.

correct. 


> You mentioned in one of the mails that went past that you'd seen
> drivers enforcing VM_LOCKED in vm_flags: aren't those just drivers
> copying other drivers which did so, but achieving nothing thereby,
> to be cleaned up in due course?  (The pages aren't even on LRU.)


I would like to know which, because in general this is a security hole:
Any driver that depends on locked meaning "doesn't move" can be fooled
by the user into becoming unlocked... (by virtue of having another
thread do an munlock on the memory). As such no kernel driver should 
depend on this, and as far as I know, no kernel driver actually does.
(early infiniband drivers used to, but they fixed that well before
things got merged to use the get_user_pages API, exactly for this
reason)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2006-05-24  2:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-22 19:31 Hugh Dickins
2006-05-22 20:29 ` Andrew Morton
2006-05-23  8:17   ` Nick Piggin
2006-05-23 14:55   ` Hugh Dickins
2006-05-23 16:24 ` Christoph Lameter
2006-05-23 19:21   ` Hugh Dickins
2006-05-23 19:31     ` Christoph Lameter
2006-05-23 20:34       ` Hugh Dickins
2006-05-23 21:16         ` Christoph Lameter
2006-05-23 21:17         ` Chen, Kenneth W
2006-05-23 21:40           ` update_mmu_cache vs. lazy_mmu_prot_update Christoph Lameter
2006-05-24 14:12             ` Hugh Dickins
2006-05-23 22:28         ` remove VM_LOCKED before remap_pfn_range and drop VM_SHM Christoph Lameter
2006-05-24 14:57           ` Hugh Dickins
2006-05-24  2:25         ` Arjan van de Ven [this message]
2006-05-24 15:10           ` tracking dirty pages patches Hugh Dickins
2006-05-25  2:26             ` Arjan van de Ven
2006-05-23 16:41 ` David Howells
2006-05-23 23:07 ` Peter Zijlstra
2006-05-24 14:20   ` Hugh Dickins

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=1148437514.3049.18.camel@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=dhowells@redhat.com \
    --cc=hugh@veritas.com \
    --cc=linux-mm@kvack.org \
    --cc=rohitseth@google.com \
    --cc=torvalds@osdl.org \
    /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