linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@xenotime.net>
To: Christopher Yeoh <cyeoh@au1.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-man@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH] Cross Memory Attach v4
Date: Tue, 26 Jul 2011 21:55:54 -0700	[thread overview]
Message-ID: <20110726215554.f87b403e.rdunlap@xenotime.net> (raw)
In-Reply-To: <20110727125342.5637308d@lilo>

On Wed, 27 Jul 2011 12:53:42 +0930 Christopher Yeoh wrote:

> Hi Andrew,
> 
> Here's an updated version of the Cross Memory Attach patch. Changes
> since the v3:
> 
> - Adds x86_64 specific wire up
> - Changes behaviour so process_vm_readv and process_vm_writev return
>   the number of bytes successfully read or written even if an error
>   occurs
> - Adds more kernel doc interface comments 
> - rename of some internal functions (process_vm_rw_check_iovecs, 
>   process_vm_rw) so they make more sense. 
> 
> Still need to do benchmarking to see if the optimisation for small
> copies using a local on-stack array in process_vm_rw_core is worth it. 

It's nice to include a diffstat so that people can get a quick patch
summary and see what files are touched.

> diffstat  -w 70 -p 1 cma-v4.patch 
 arch/powerpc/include/asm/systbl.h  |    2 
 arch/powerpc/include/asm/unistd.h  |    4 
 arch/x86/ia32/ia32entry.S          |    2 
 arch/x86/include/asm/unistd_32.h   |    4 
 arch/x86/include/asm/unistd_64.h   |    4 
 arch/x86/kernel/syscall_table_32.S |    2 
 fs/aio.c                           |    4 
 fs/compat.c                        |    7 
 fs/read_write.c                    |    8 
 include/linux/compat.h             |    3 
 include/linux/fs.h                 |    7 
 include/linux/syscalls.h           |   13 
 kernel/sys_ni.c                    |    4 
 mm/Makefile                        |    3 
 mm/process_vm_access.c             |  482 +++++++++++++++++++++++++++
 security/keys/compat.c             |    2 
 security/keys/keyctl.c             |    2 
 17 files changed, 536 insertions(+), 17 deletions(-)


> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
> new file mode 100644
> index 0000000..a0e3cfb
> --- /dev/null
> +++ b/mm/process_vm_access.c
> @@ -0,0 +1,482 @@
> +/*
> + *  linux/mm/process_vm_access.c
> + *
> + *  Copyright (C) 2010-2011 Christopher Yeoh <cyeoh@au1.ibm.com>, IBM Corp.

Any license for this file?  maybe GPL?

> + */
> +
> +#include <linux/mm.h>
> +#include <linux/uio.h>
> +#include <linux/sched.h>
> +#include <linux/highmem.h>
> +#include <linux/ptrace.h>
> +#include <linux/slab.h>
> +#include <linux/syscalls.h>
> +
> +#ifdef CONFIG_COMPAT
> +#include <linux/compat.h>
> +#endif
> +
> +/*

Any problem with using
/**
so that these are proper kernel-doc notation?
(for all [4] functions here that have such notation)


> + * process_vm_rw_pages - read/write pages from task specified
> + * @task: task to read/write from
> + * @mm: mm for task
> + * @process_pages: struct pages area that can store at least
> + *  nr_pages_to_copy struct page pointers
> + * @pa: address of page in task to start copying from/to
> + * @start_offset: offset in page to start copying from/to
> + * @len: number of bytes to copy
> + * @lvec: iovec array specifying where to copy to/from
> + * @lvec_cnt: number of elements in iovec array
> + * @lvec_current: index in iovec array we are up to
> + * @lvec_offset: offset in bytes from current iovec iov_base we are up to
> + * @vm_write: 0 means copy from, 1 means copy to
> + * @nr_pages_to_copy: number of pages to copy
> + * @bytes_copied: returns number of bytes successfully copied
> + * Returns 0 on success, error code otherwise
> + */
> +static int process_vm_rw_pages(struct task_struct *task,
> +			       struct mm_struct *mm,
> +			       struct page **process_pages,
> +			       unsigned long pa,
> +			       unsigned long start_offset,
> +			       unsigned long len,
> +			       const struct iovec *lvec,
> +			       unsigned long lvec_cnt,
> +			       unsigned long *lvec_current,
> +			       size_t *lvec_offset,
> +			       int vm_write,
> +			       unsigned int nr_pages_to_copy,
> +			       ssize_t *bytes_copied)
> +{


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-07-27  4:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-27  3:23 [PATCH] Cross Memory Attach v4 Christopher Yeoh
2011-07-27  4:55 ` Randy Dunlap [this message]
2011-07-27 14:49   ` [PATCH] Cross Memory Attach v4 (patch updated) Christopher Yeoh

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=20110726215554.f87b403e.rdunlap@xenotime.net \
    --to=rdunlap@xenotime.net \
    --cc=akpm@linux-foundation.org \
    --cc=cyeoh@au1.ibm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).