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>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"gregkh@suse.de" <gregkh@suse.de>,
	"broonie@opensource.wolfsonmicro.com" 
	<broonie@opensource.wolfsonmicro.com>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
	"avi@qumranet.com" <avi@qumranet.com>,
	"andi@firstfloor.org" <andi@firstfloor.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	WANG Cong <xiyou.wangcong@gmail.com>,
	Mike Smith <scgtrp@gmail.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: [PATCH] devmem: handle partial kmem write/read
Date: Tue, 15 Sep 2009 10:05:18 +0800	[thread overview]
Message-ID: <20090915020518.GB15159@localhost> (raw)
In-Reply-To: <20090915105255.091451c6.kamezawa.hiroyu@jp.fujitsu.com>

On Tue, Sep 15, 2009 at 09:52:55AM +0800, KAMEZAWA Hiroyuki wrote:
> On Tue, 15 Sep 2009 09:24:48 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> 
> > On Mon, 14 Sep 2009 12:34:44 +0800
> > Wu Fengguang <fengguang.wu@intel.com> wrote:
> > 
> > > Hi Kame,
> > > 
> > > This patch needs more work. I first intent to fix a bug:
> > > 
> > >                         sz = vwrite(kbuf, (char *)p, sz);
> > >                         p += sz;
> > >                 }
> > > 
> > > So if the returned len is 0, the kbuf/p pointers will mismatch. 
> > > 
> > > Then I realize it changed the write behavior. The current vwrite()
> > > behavior is strange, it returns 0 if _whole range_ is hole, otherwise
> > > ignores the hole silently. So holes can be treated differently even in
> > > the original code.
> > > 
> > Ah, ok...
> > 
> 
> I'd like to post a fix...but it seems you are woriking.
> Hmm, I'll post a patch including your fix (and your sign.)
> Is it ok ?

Sure OK. You can work based on my patches. Many of them are in -mm now
and there are three more. I'll show you in a series.

Thanks,
Fengguang

> > > I'm not really sure about the right behavior. KAME-san, do you have
> > > any suggestions?
> > > 
> > maybe following make sense.
> > =
> > written = vwrite(kbuf, (char *p), sz);
> > if (!written) // whole vmem was a hole
> > 	written = sz;
> > ==
> > needs fix.
> > 
> > Anyway, I wonder kmem is broken. It's should be totally rewritten.
> > 
> > For example, this doesn't check anything.
> > ==
> >         if (p < (unsigned long) high_memory) {
> > 
> > ==
> > 
> > But....are there users ?
> > If necessary, I'll write some...
> > 
> > Thanks,
> > -Kame
> > 
> > 
> > > Thanks,
> > > Fengguang
> > > 
> > > On Mon, Sep 14, 2009 at 11:29:01AM +0800, Wu Fengguang wrote:
> > > > Current vwrite silently ignores vwrite() to vmap holes.
> > > > Better behavior should be stop the write and return
> > > > on such holes.
> > > > 
> > > > Also return on partial read, which may happen in future
> > > > (eg. hit hwpoison pages).
> > > > 
> > > > CC: Andi Kleen <andi@firstfloor.org>
> > > > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> > > > ---
> > > >  drivers/char/mem.c |   30 ++++++++++++++++++------------
> > > >  1 file changed, 18 insertions(+), 12 deletions(-)
> > > > 
> > > > --- linux-mm.orig/drivers/char/mem.c	2009-09-14 10:59:50.000000000 +0800
> > > > +++ linux-mm/drivers/char/mem.c	2009-09-14 11:06:25.000000000 +0800
> > > > @@ -444,18 +444,22 @@ static ssize_t read_kmem(struct file *fi
> > > >  		if (!kbuf)
> > > >  			return -ENOMEM;
> > > >  		while (count > 0) {
> > > > +			unsigned long n;
> > > > +
> > > >  			sz = size_inside_page(p, count);
> > > > -			sz = vread(kbuf, (char *)p, sz);
> > > > -			if (!sz)
> > > > +			n = vread(kbuf, (char *)p, sz);
> > > > +			if (!n)
> > > >  				break;
> > > > -			if (copy_to_user(buf, kbuf, sz)) {
> > > > +			if (copy_to_user(buf, kbuf, n)) {
> > > >  				free_page((unsigned long)kbuf);
> > > >  				return -EFAULT;
> > > >  			}
> > > > -			count -= sz;
> > > > -			buf += sz;
> > > > -			read += sz;
> > > > -			p += sz;
> > > > +			count -= n;
> > > > +			buf += n;
> > > > +			read += n;
> > > > +			p += n;
> > > > +			if (n < sz)
> > > > +				break;
> > > >  		}
> > > >  		free_page((unsigned long)kbuf);
> > > >  	}
> > > > @@ -551,11 +555,13 @@ static ssize_t write_kmem(struct file * 
> > > >  				free_page((unsigned long)kbuf);
> > > >  				return -EFAULT;
> > > >  			}
> > > > -			sz = vwrite(kbuf, (char *)p, sz);
> > > > -			count -= sz;
> > > > -			buf += sz;
> > > > -			virtr += sz;
> > > > -			p += sz;
> > > > +			n = vwrite(kbuf, (char *)p, sz);
> > > > +			count -= n;
> > > > +			buf += n;
> > > > +			virtr += n;
> > > > +			p += n;
> > > > +			if (n < sz)
> > > > +				break;
> > > >  		}
> > > >  		free_page((unsigned long)kbuf);
> > > >  	}
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 

  reply	other threads:[~2009-09-15  2:05 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14  3:29 [PATCH] devmem: handle partial kmem write/read Wu Fengguang
2009-09-14  4:34 ` Wu Fengguang
2009-09-15  0:24   ` KAMEZAWA Hiroyuki
2009-09-15  1:52     ` KAMEZAWA Hiroyuki
2009-09-15  2:05       ` Wu Fengguang [this message]
2009-09-15  2:02     ` Wu Fengguang
2009-09-15  2:31       ` KAMEZAWA Hiroyuki
2009-09-15  2:57         ` Wu Fengguang
2009-09-15  7:58 ` Question: how to handle too big f_pos " KAMEZAWA Hiroyuki
2009-09-15  8:11   ` Wu Fengguang
2009-09-15  9:52   ` Hugh Dickins
2009-09-16  5:29   ` [RFC][PATCH][bugfix] more checks for negative f_pos handling (Was Re: Question: how to handle too big f_pos KAMEZAWA Hiroyuki
2009-09-16  8:20     ` Américo Wang
2009-09-16  8:44       ` KAMEZAWA Hiroyuki
2009-09-16  9:13         ` Américo Wang
2009-09-16 12:06           ` KAMEZAWA Hiroyuki
2009-09-17  3:06             ` Américo Wang
2009-09-17  5:53     ` [RFC][PATCH][bugfix] more checks for negative f_pos handling v2 KAMEZAWA Hiroyuki
2009-09-17  6:07       ` [RFC][PATCH][bugfix] more checks for negative f_pos handling v3 KAMEZAWA Hiroyuki
2009-09-17  6:21         ` Wu Fengguang
2009-09-17  6:31           ` KAMEZAWA Hiroyuki
2009-09-17  6:53             ` Wu Fengguang
2009-09-17  6:51           ` [RFC][PATCH][bugfix] more checks for negative f_pos handling v4 KAMEZAWA Hiroyuki
2009-09-17  7:14             ` Wu Fengguang
2009-09-17  7:23               ` KAMEZAWA Hiroyuki
2009-09-17  7:30                 ` Wu Fengguang
2009-09-17  9:42                 ` Wu Fengguang
2009-09-17 10:54                   ` KAMEZAWA Hiroyuki
2009-09-17 10:58                     ` KAMEZAWA Hiroyuki
2009-09-17 12:40                     ` Wu Fengguang
2009-09-18  0:02                       ` KAMEZAWA Hiroyuki
2009-09-18  2:25                         ` Américo Wang

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=20090915020518.GB15159@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=avi@qumranet.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=gregkh@suse.de \
    --cc=johannes@sipsolutions.net \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=nickpiggin@yahoo.com.au \
    --cc=scgtrp@gmail.com \
    --cc=xiyou.wangcong@gmail.com \
    /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.