2010-11-02 03:37:22

by Christopher Yeoh

[permalink] [raw]
Subject: Re: [RFC][PATCH] Cross Memory Attach

On Thu, 16 Sep 2010 11:26:36 +0200
Avi Kivity <[email protected]> wrote:
> On 09/16/2010 03:18 AM, Christopher Yeoh wrote:
> > On Wed, 15 Sep 2010 23:46:09 +0900
> > Bryan Donlan<[email protected]> wrote:
> >
> > > On Wed, Sep 15, 2010 at 19:58, Avi Kivity<[email protected]> wrote:
> > >
> > > > Instead of those two syscalls, how about a vmfd(pid_t pid,
> > > > ulong start, ulong len) system call which returns an file
> > > > descriptor that represents a portion of the process address
> > > > space. You can then use preadv() and pwritev() to copy
> > > > memory, and io_submit(IO_CMD_PREADV) and
> > > > io_submit(IO_CMD_PWRITEV) for asynchronous variants
> > > > (especially useful with a dma engine, since that adds latency).
> > > >
> > > > With some care (and use of mmu_notifiers) you can even mmap()
> > > > your vmfd and access remote process memory directly.
> > >
> > > Rather than introducing a new vmfd() API for this, why not just
> > > add implementations for these more efficient operations to the
> > > existing /proc/$pid/mem interface?
> >
> > Perhaps I'm misunderstanding something here, but
> > accessing /proc/$pid/mem requires ptracing the target process.
> > We can't really have all these MPI processes ptraceing each other
> > just to send/receive a message....
> >
>
> You could have each process open /proc/self/mem and pass the fd using
> SCM_RIGHTS.
>
> That eliminates a race; with copy_to_process(), by the time the pid
> is looked up it might designate a different process.

Just to revive an old thread (I've been on holidays), but this doesn't
work either. the ptrace check is done by mem_read (eg on each read) so
even if you do pass the fd using SCM_RIGHTS, reads on the fd still
fail.

So unless there's good reason to believe that the ptrace permission
check is no longer needed, the /proc/pid/mem interface doesn't seem to
be an option for what we want to do.

Oh and interestingly reading from /proc/pid/mem involves a double copy
- copy to a temporary kernel page and then out to userspace. But that is
fixable.

Regards,

Chris
--
[email protected]


2010-11-02 11:11:13

by Avi Kivity

[permalink] [raw]
Subject: Re: [RFC][PATCH] Cross Memory Attach

On 11/01/2010 11:37 PM, Christopher Yeoh wrote:
> >
> > You could have each process open /proc/self/mem and pass the fd using
> > SCM_RIGHTS.
> >
> > That eliminates a race; with copy_to_process(), by the time the pid
> > is looked up it might designate a different process.
>
> Just to revive an old thread (I've been on holidays), but this doesn't
> work either. the ptrace check is done by mem_read (eg on each read) so
> even if you do pass the fd using SCM_RIGHTS, reads on the fd still
> fail.
>
> So unless there's good reason to believe that the ptrace permission
> check is no longer needed, the /proc/pid/mem interface doesn't seem to
> be an option for what we want to do.
>

Perhaps move the check to open(). I can understand the desire to avoid
letting random processes peek each other's memory, but once a process
has opened its own /proc/self/mem and explicitly passed it to another,
we should allow it.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.