From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
Hugh Dickins <hugh@veritas.com>,
Linux Memory Management <linux-mm@kvack.org>,
Andrew Morton <akpm@osdl.org>, Jes Sorensen <jes@sgi.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: ptrace and pfn mappings
Date: Tue, 10 Oct 2006 13:42:55 +1000 [thread overview]
Message-ID: <1160451775.32237.86.camel@localhost.localdomain> (raw)
In-Reply-To: <20061010030344.GF15822@wotan.suse.de>
> Hold your per-object lock? I'm not talking about using mmap_sem for
> migration, but the per-object lock in access_process_vm. I thought
> this prevented migration?
As I said in my previous mail. access_process_vm() is a generic function
called by ptrace, it has 0 knowledge of the internal locking scheme of
a driver providing a nopage/nopfn for a vma.
> OK, just do one pfn at a time. For ptrace that is fine. access_process_vm
> already copies from source into kernel buffer, then kernel buffer into
> target.
Even one pfn at a time ... the only way would be if we also took the PTE
lock during the copy in fact. That's the only lock that would provide
that same guarantees as an access I think.
Ben.
--
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>
next prev parent reply other threads:[~2006-10-10 3:42 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-09 16:12 [rfc] 2.6.19-rc1-git5: consolidation of file backed fault handlers Nick Piggin
2006-10-09 16:12 ` [patch 1/5] mm: fault vs invalidate/truncate check Nick Piggin
2006-10-09 16:12 ` [patch 2/5] mm: fault vs invalidate/truncate race fix Nick Piggin
2006-10-09 21:10 ` Mark Fasheh
2006-10-10 1:10 ` Nick Piggin
2006-10-11 18:34 ` Mark Fasheh
2006-10-12 3:28 ` Nick Piggin
2006-10-09 16:12 ` [patch 3/5] mm: fault handler to replace nopage and populate Nick Piggin
2006-10-09 16:12 ` [patch 4/5] mm: add vm_insert_pfn helpler Nick Piggin
2006-10-09 21:03 ` Benjamin Herrenschmidt
2006-10-10 0:42 ` Nick Piggin
2006-10-10 1:11 ` faults and signals Benjamin Herrenschmidt
2006-10-10 1:20 ` Nick Piggin
2006-10-10 1:58 ` Benjamin Herrenschmidt
2006-10-10 2:00 ` Benjamin Herrenschmidt
2006-10-10 2:04 ` Nick Piggin
2006-10-10 2:07 ` Benjamin Herrenschmidt
2006-10-10 1:16 ` ptrace and pfn mappings Benjamin Herrenschmidt
2006-10-10 2:23 ` Nick Piggin
2006-10-10 2:47 ` Benjamin Herrenschmidt
2006-10-10 2:56 ` Benjamin Herrenschmidt
2006-10-10 3:03 ` Nick Piggin
2006-10-10 3:42 ` Benjamin Herrenschmidt [this message]
2006-10-10 2:58 ` Nick Piggin
2006-10-10 3:40 ` Benjamin Herrenschmidt
2006-10-10 3:46 ` Nick Piggin
2006-10-10 4:58 ` Benjamin Herrenschmidt
2006-10-10 12:31 ` Christoph Hellwig
2006-10-10 12:42 ` Benjamin Herrenschmidt
2006-10-10 18:06 ` Hugh Dickins
2006-10-09 16:13 ` [patch 5/5] mm: merge nopfn with fault handler Nick Piggin
2006-10-09 20:57 ` [rfc] 2.6.19-rc1-git5: consolidation of file backed fault handlers Benjamin Herrenschmidt
2006-10-09 21:00 ` Benjamin Herrenschmidt
2006-10-10 0:53 ` Nick Piggin
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=1160451775.32237.86.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=jes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=npiggin@suse.de \
/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