From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: kamezawa.hiroyu@jp.fujitsu.com, 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 14:30:31 -0700 [thread overview]
Message-ID: <20090804143031.b9769a13.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090803201845.c3ae49b5.kamezawa.hiroyu@jp.fujitsu.com>
On Mon, 3 Aug 2009 20:18:45 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> vread/vwrite access vmalloc area without checking there is a page or not.
> In most case, this works well.
>
> In old ages, the caller of get_vm_ara() is only IOREMAP and there is no
> memory hole within vm_struct's [addr...addr + size - PAGE_SIZE]
> ( -PAGE_SIZE is for a guard page.)
>
> After per-cpu-alloc patch, it uses get_vm_area() for reserve continuous
> virtual address but remap _later_. There tend to be a hole in valid vmalloc
> area in vm_struct lists.
> Then, skip the hole (not mapped page) is necessary.
> This patch updates vread/vwrite() for avoiding memory hole.
>
> Routines which access vmalloc area without knowing for which addr is used
> are
> - /proc/kcore
> - /dev/kmem
>
> kcore checks IOREMAP, /dev/kmem doesn't. After this patch, IOREMAP is
> checked and /dev/kmem will avoid to read/write it.
> Fixes to /proc/kcore will be in the next patch in series.
>
> Changelog v2->v3:
> - fixed typos.
> - use kmap. (if not using kmap, we have to add lock here.)
> - fixed PAGE_MASK miss-use.
> Changelog v1->v2:
> - enhanced comments.
> - treat IOREMAP as hole always.
> - zero-fill memory hole if [addr...addr+size] includes valid pages.
> - returns 0 if [addr...addr+size) includes no valid pages.
>
> ...
>
> +static int aligned_vread(char *buf, char *addr, unsigned long count)
> +{
> + struct page *p;
> + int copied = 0;
> +
> + while (count) {
> + unsigned long offset, length;
> +
> + offset = (unsigned long)addr & ~PAGE_MASK;
> + length = PAGE_SIZE - offset;
> + if (length > count)
> + length = count;
> + p = vmalloc_to_page(addr);
> + /*
> + * 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.
> + void *map = kmap_atomic(p, KM_USER1);
> + memcpy(buf, map + offset, length);
> + kunmap_atomic(map, KM_USER1);
Can use clear_highpage().
> + } else
> + memset(buf, 0, length);
> +
> + addr += length;
> + buf += length;
> + copied += length;
> + count -= length;
> + }
> + return copied;
> +}
> +
> +static int aligned_vwrite(char *buf, char *addr, unsigned long count)
> +{
> + struct page *p;
> + int copied = 0;
> +
> + while (count) {
> + unsigned long offset, length;
> +
> + offset = (unsigned long)addr & ~PAGE_MASK;
> + length = PAGE_SIZE - offset;
> + if (length > count)
> + length = count;
> + p = vmalloc_to_page(addr);
> + /*
> + * 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 */
> + void *map = kmap_atomic(p, KM_USER1);
> + memcpy(map + offset, buf, length);
> + kunmap_atomic(map, KM_USER1);
clear_highpage().
> + }
> + addr += length;
> + buf += length;
> + copied += length;
> + count -= length;
> + }
> + return copied;
> +}
next prev parent reply other threads:[~2009-08-04 21:31 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 [this message]
2009-08-05 1:08 ` KAMEZAWA Hiroyuki
2009-08-05 1:24 ` Andrew Morton
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=20090804143031.b9769a13.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.