All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Christoph Lameter <clameter@sgi.com>, Ingo Molnar <mingo@elte.hu>,
	Tejun Heo <tj@kernel.org>, Nick Piggin <npiggin@suse.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] vmalloc: ignore vmalloc area holes in vwrite()
Date: Tue, 15 Sep 2009 13:21:51 +0800	[thread overview]
Message-ID: <20090915052151.GA30012@localhost> (raw)
In-Reply-To: <20090915121829.d78be0b8.kamezawa.hiroyu@jp.fujitsu.com>

On Tue, Sep 15, 2009 at 11:18:29AM +0800, KAMEZAWA Hiroyuki wrote:
> On Tue, 15 Sep 2009 11:15:07 +0800
> Wu Fengguang <fengguang.wu@intel.com> wrote:
> 
> > Hi Kame,
> > 
> > I'll go out for a while. If you are going to do your improvements to
> > vmalloc.c, please feel free to do so. I can rebase the hwpoison bits
> > after yours.
> > 
> > I could do the kmem part(in a modified patch 2/3) and let it return
> > any error code vread/vwrite reports.  Ideally the kmem read/write
> > could do
> > 
> >         if (zero bytes successfully read/written)
> >                 return error_code;
> >         else
> >                 return bytes_so_far;
> > 
> > Do you agree?
> > 
> Okay. I'll write patches for vread/vwrite. And make them just return bool.

bool may not be sufficient? For obviously you need to return -EFAULT
for invalid address and I need to return -EIO for hwpoison pages.
(I assume you put is_vmalloc_or_module_addr() immediately before the
vmalloc_to_page() calls in vmalloc.c, which seems a more natural place
than in mem.c.)

Thanks,
Fengguang

>  true .....requested area includes valid memory range and worth to be copied.
>  false.....no valid range found.
> 
> Thanks,
> -Kame
> 
> 
> 
> 
> > Thanks,
> > Fengguang
> > 
> > On Tue, Sep 15, 2009 at 10:34:25AM +0800, KAMEZAWA Hiroyuki wrote:
> > > On Tue, 15 Sep 2009 10:18:52 +0800
> > > Wu Fengguang <fengguang.wu@intel.com> wrote:
> > > 
> > > > Siliently ignore all vmalloc area holes in vwrite(),
> > > > and report success to the caller even if nothing is written.
> > > > 
> > > > CC: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> > > 
> > > Why don't you modify vread() at the same time ?
> > > Because /proc/kcore ignores return value of vread(), I think you can
> > > modify it without no side-effect.
> > > 
> > > Regards,
> > > -Kame
> > > 
> > > > ---
> > > >  mm/vmalloc.c |   13 ++-----------
> > > >  1 file changed, 2 insertions(+), 11 deletions(-)
> > > > 
> > > > --- linux-mm.orig/mm/vmalloc.c	2009-09-15 10:08:33.000000000 +0800
> > > > +++ linux-mm/mm/vmalloc.c	2009-09-15 10:14:18.000000000 +0800
> > > > @@ -1805,10 +1805,8 @@ finished:
> > > >   *	@addr:		vm address.
> > > >   *	@count:		number of bytes to be read.
> > > >   *
> > > > - *	Returns # of bytes which addr and buf should be incresed.
> > > > + *	Returns # of bytes which addr and buf should be increased.
> > > >   *	(same number to @count).
> > > > - *	If [addr...addr+count) doesn't includes any intersect with valid
> > > > - *	vmalloc area, returns 0.
> > > >   *
> > > >   *	This function checks that addr is a valid vmalloc'ed area, and
> > > >   *	copy data from a buffer to the given addr. If specified range of
> > > > @@ -1816,8 +1814,6 @@ finished:
> > > >   *	proper area of @buf. If there are memory holes, no copy to hole.
> > > >   *	IOREMAP area is treated as memory hole and no copy is done.
> > > >   *
> > > > - *	If [addr...addr+count) doesn't includes any intersects with alive
> > > > - *	vm_struct area, returns 0.
> > > >   *	@buf should be kernel's buffer. Because	this function uses KM_USER0,
> > > >   *	the caller should guarantee KM_USER0 is not used.
> > > >   *
> > > > @@ -1834,7 +1830,6 @@ long vwrite(char *buf, char *addr, unsig
> > > >  	struct vm_struct *tmp;
> > > >  	char *vaddr;
> > > >  	unsigned long n, buflen;
> > > > -	int copied = 0;
> > > >  
> > > >  	/* Don't allow overflow */
> > > >  	if ((unsigned long) addr + count < count)
> > > > @@ -1856,18 +1851,14 @@ long vwrite(char *buf, char *addr, unsig
> > > >  		n = vaddr + tmp->size - PAGE_SIZE - addr;
> > > >  		if (n > count)
> > > >  			n = count;
> > > > -		if (!(tmp->flags & VM_IOREMAP)) {
> > > > +		if (!(tmp->flags & VM_IOREMAP))
> > > >  			aligned_vwrite(buf, addr, n);
> > > > -			copied++;
> > > > -		}
> > > >  		buf += n;
> > > >  		addr += n;
> > > >  		count -= n;
> > > >  	}
> > > >  finished:
> > > >  	read_unlock(&vmlist_lock);
> > > > -	if (!copied)
> > > > -		return 0;
> > > >  	return buflen;
> > > >  }
> > > >  
> > > > 
> > > > -- 
> > > > 
> > > > 
> > 

  reply	other threads:[~2009-09-15  5:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15  2:18 [PATCH 0/3] /proc/kmem cleanups and hwpoison bits Wu Fengguang
2009-09-15  2:18 ` [PATCH 1/3] vmalloc: ignore vmalloc area holes in vwrite() Wu Fengguang
2009-09-15  2:34   ` KAMEZAWA Hiroyuki
2009-09-15  3:15     ` Wu Fengguang
2009-09-15  3:18       ` KAMEZAWA Hiroyuki
2009-09-15  5:21         ` Wu Fengguang [this message]
2009-09-15  2:18 ` [PATCH 2/3] devmem: handle partial kmem write/read Wu Fengguang
2009-09-15  2:38   ` KAMEZAWA Hiroyuki
2009-09-15  9:01     ` Wu Fengguang
2009-09-15  9:03       ` Wu Fengguang
2009-09-15  2:18 ` [PATCH 3/3] HWPOISON: prevent /dev/kmem users from accessing hwpoison pages Wu Fengguang
2009-09-15  2:45   ` KAMEZAWA Hiroyuki
2009-09-15  3:09 ` [PATCH 0/3] /proc/kmem cleanups and hwpoison bits KAMEZAWA Hiroyuki
2009-09-15  8:22   ` Wu Fengguang
2009-09-15 10:16     ` Hugh Dickins
2009-09-16  0:39       ` KAMEZAWA Hiroyuki
2009-09-16  0:39       ` Wu Fengguang
2009-09-16  9:01       ` Geert Uytterhoeven
2009-09-16  9:01         ` Geert Uytterhoeven
2009-09-16  9:01         ` Geert Uytterhoeven
2009-09-16 11:26         ` Hugh Dickins
2009-09-16 11:26           ` Hugh Dickins
2009-09-16 11:42           ` Geert Uytterhoeven
2009-09-16 11:42             ` Geert Uytterhoeven
2009-09-16 11:42             ` Geert Uytterhoeven
2009-09-16 11:26         ` 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=20090915052151.GA30012@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=tj@kernel.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 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.