All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Richard F Weber <rfweber@link.com>,
	linux-mm@kvack.org
Subject: Re: About reading /proc/*/mem
Date: Wed, 2 May 2001 11:25:51 +0100	[thread overview]
Message-ID: <20010502112551.B26638@redhat.com> (raw)
In-Reply-To: <Pine.GSO.4.21.0105011231330.9771-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Tue, May 01, 2001 at 12:35:29PM -0400

Hi,

On Tue, May 01, 2001 at 12:35:29PM -0400, Alexander Viro wrote:
> 
> On 1 May 2001, Eric W. Biederman wrote:
> 
> > > Unfortunately, ptrace() probobally isn't going to allow me to do that.  
> > > So my next question is does opening /proc/*/mem force the child process 
> > > to stop on every interrupt (just like ptrace?)
> > 
> > 
> > The not stopping the child should be the major difference between
> > /proc/*/mem and ptrace.
> 
> Could somebody tell me what would one do with data read from memory
> of process that is currently running?

As long as we have the appropriate page table lock while doing the
physical page lookup, and grab a refcount on the page with the lock
held, we'll get a valid physical memory location to read to the user.
We don't need any stronger guarantee than that --- if the target
process is playing mmap games or modifying the memory while the read
happens, the result is unpredictable but safe.

Cheers,
 Stephen
--
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.eu.org/Linux-MM/

  parent reply	other threads:[~2001-05-02 10:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01 13:33 About reading /proc/*/mem Richard F Weber
2001-05-01 15:27 ` Eric W. Biederman
2001-05-01 16:35   ` Alexander Viro
2001-05-01 17:03     ` Richard F Weber
2001-05-01 17:14       ` Alexander Viro
2001-05-02 10:25     ` Stephen C. Tweedie [this message]
2001-05-02 11:39     ` Richard F Weber
2001-05-03 17:51       ` Richard F Weber
2001-05-01 16:53   ` Richard F Weber
2001-05-01 17:09     ` Alexander Viro
2001-05-01 17:29       ` Richard F Weber

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=20010502112551.B26638@redhat.com \
    --to=sct@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-mm@kvack.org \
    --cc=rfweber@link.com \
    --cc=viro@math.psu.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.