From: Amerigo Wang <xiyou.wangcong@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Amerigo Wang <xiyou.wangcong@gmail.com>,
Mike Smith <scgtrp@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUGFIX][PATCH 1/3] fix vread/vwrite to be aware of memory hole
Date: Mon, 3 Aug 2009 17:10:19 +0800 [thread overview]
Message-ID: <20090803091019.GC6016@cr0.nay.redhat.com> (raw)
In-Reply-To: <65d1a0e3dc0e5fa357f392f0552b4519.squirrel@webmail-b.css.fujitsu.com>
On Fri, Jul 31, 2009 at 07:32:15PM +0900, KAMEZAWA Hiroyuki wrote:
>Amerigo Wang さんは書きました:
>> On Fri, Jul 31, 2009 at 04:11:28PM +0900, KAMEZAWA Hiroyuki wrote:
>>>From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>>>
>>>vread/vwrite access vmalloc area without checking there is a page or not.
>>>
>>>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.
>>>
>>>And, this itself fixes the bug as
>>># dd if=/dev/kmem of=/dev/null bs=1024 count=1048576 skip=3145728
>>>can cause panic.
>>
>>
>> What panic? :-) Would you mind to put it here?
>>
>It directly reboot ;( and no log.
>plz try.
I tried it on an x86_64 machine, no panic, just:
dd: reading `/dev/kmem': Bad address
Only appears on i386? :)
>>>- return buf - buf_start;
>>>+
>>>+ if (buf == buf_start)
>>>+ return 0;
>>>+ /* zero-fill memory holes */
>>>+ if (buf != buf_start + buflen)
>>>+ memset(buf, 0, buflen - (buf - buf_start));
>>
>>
>> Is this necessary?
>>
>I wrote "filled by zero" and thinks it's sane, then does this.
>Now, /proc/kcore allocates memory by kzalloc(), this is redundant.
>/dev/kmem doesn't do that.
OK.
>ouch..
>
>Thank you for review.
>I'm sorry that new version will not appear until next week.
>I can't access x86-32 in the weekend.
No problem, feel free to do it at any time that is convinient
for you.
Thanks.
next prev parent reply other threads:[~2009-08-03 9:08 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 [this message]
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
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=20090803091019.GC6016@cr0.nay.redhat.com \
--to=xiyou.wangcong@gmail.com \
--cc=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 \
/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.