From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: scgtrp@gmail.com, bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org, xiyou.wangcong@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [BUGFIX][PATCH 2/3] kcore: fix vread/vwrite to be aware of holes.
Date: Tue, 4 Aug 2009 18:24:57 -0700 [thread overview]
Message-ID: <20090804182457.8135110f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090805100843.dbdabcfa.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 5 Aug 2009 10:08:43 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > + /*
> > > + * To do safe access to this _mapped_ area, we need
> > > + * lock. But adding lock here means that we need to add
> > > + * overhead of vmalloc()/vfree() calles for this _debug_
> > > + * interface, rarely used. Instead of that, we'll use
> > > + * kmap() and get small overhead in this access function.
> > > + */
> > > + if (p) {
> > > + /* we can expect USR1 is not used */
> >
> > It would be nice if the comment were to explain _why_ KM_USER1 is known
> > to be free here.
> >
> ok, will do. Hmm, but KM_USR0 is better ?
> I'm not sure difference between KM_USR0/KM_USR1...
KM_USER0 is conventionally the first one to use. We only use KM_USER1
if it is known that KM_USER0 is already used.
>
>
> >
> > > + void *map = kmap_atomic(p, KM_USER1);
> > > + memcpy(buf, map + offset, length);
> > > + kunmap_atomic(map, KM_USER1);
> >
> > Can use clear_highpage().
> >
> ah, "buf" is expected to be kmalloc'ed buffer. I'll explain it in Usage
> or adds comment.
>
argh, memcpy != memset. I knew that ;)
next prev parent reply other threads:[~2009-08-05 1:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-13850-10286@http.bugzilla.kernel.org/>
2009-07-28 23:05 ` [Bugme-new] [Bug 13850] New: reading /proc/kcore causes oops Andrew Morton
2009-07-28 23:48 ` KAMEZAWA Hiroyuki
2009-07-29 2:46 ` Mike Smith
2009-07-29 3:32 ` KAMEZAWA Hiroyuki
2009-07-29 8:36 ` [RFC][PATCH 1/2] vmalloc: reorder unmap and removal entry KAMEZAWA Hiroyuki
2009-07-29 8:48 ` [RFC][PATCH 2/2] vmalloc: vread vwrite avoid memory hole KAMEZAWA Hiroyuki
2009-07-29 9:59 ` Amerigo Wang
2009-07-29 11:51 ` KAMEZAWA Hiroyuki
2009-07-31 9:38 ` Amerigo Wang
2009-07-29 9:40 ` [RFC][PATCH 1/2] vmalloc: reorder unmap and removal entry Amerigo Wang
2009-07-29 11:53 ` KAMEZAWA Hiroyuki
2009-07-31 7:07 ` [BUGFIX][PATCH 0/3] fix bug for /proc/kcore causes panic (Was: [Bugme-new] [Bug 13850] New: reading /proc/kcore causes oops KAMEZAWA Hiroyuki
2009-07-31 7:11 ` [BUGFIX][PATCH 1/3] fix vread/vwrite to be aware of memory hole KAMEZAWA Hiroyuki
2009-07-31 9:57 ` Amerigo Wang
2009-07-31 10:32 ` KAMEZAWA Hiroyuki
2009-08-03 9:10 ` Amerigo Wang
2009-08-03 9:10 ` KAMEZAWA Hiroyuki
2009-07-31 7:12 ` [BUGFIX][PATCH 2/3] kcore should use vread KAMEZAWA Hiroyuki
2009-07-31 7:13 ` [BUGFIX][PATCH 3/3] unmap vmalloc area after hide it KAMEZAWA Hiroyuki
2009-07-31 7:21 ` [BUGFIX][PATCH 0/3] fix bug for /proc/kcore causes panic (Was: [Bugme-new] [Bug 13850] New: reading /proc/kcore causes oops KAMEZAWA Hiroyuki
2009-08-03 11:14 ` [BUGFIX][PATCH 0/3] kcore: avoid access to holes in vmalloc v3 (Was " KAMEZAWA Hiroyuki
2009-08-03 11:15 ` [BUGFIX][PATCH 1/3] unmap vmalloc area after hide it KAMEZAWA Hiroyuki
2009-08-03 11:18 ` [BUGFIX][PATCH 2/3] kcore: fix vread/vwrite to be aware of holes KAMEZAWA Hiroyuki
2009-08-04 9:23 ` Amerigo Wang
2009-08-04 9:55 ` KAMEZAWA Hiroyuki
2009-08-05 2:09 ` Amerigo Wang
2009-08-04 21:30 ` Andrew Morton
2009-08-05 1:08 ` KAMEZAWA Hiroyuki
2009-08-05 1:24 ` Andrew Morton [this message]
2009-08-05 1:39 ` KAMEZAWA Hiroyuki
2009-08-03 11:19 ` [BUGFIX][PATCH 3/3] kcore: /proc/kcore should use vread KAMEZAWA Hiroyuki
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=20090804182457.8135110f.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--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.