From: Amerigo Wang <xiyou.wangcong@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Mike Smith <scgtrp@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org,
Amerigo Wang <xiyou.wangcong@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 1/2] vmalloc: reorder unmap and removal entry
Date: Wed, 29 Jul 2009 17:40:34 +0800 [thread overview]
Message-ID: <20090729094034.GF5856@cr0.nay.redhat.com> (raw)
In-Reply-To: <20090729173600.540878a3.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, Jul 29, 2009 at 05:36:00PM +0900, KAMEZAWA Hiroyuki wrote:
>> I wonder fs/proc/kcore.c's vmalloc area access needs some fix. let me try.
>>
>> Thanks,
>Finally, I wrote 2 patches. maybe 2/2 is a fix for the bug.
>but needs comments.
>
>Comaparing 2 calls, vfree() and vread()
>==
>vfree()
> -> __vumap()
> -> remove_vm_area()
> -> free_unmap_vmap_area #
> -> try_purge_vmap_area_lazy() #
> ->__purge_vmap_area_lazy(); #
> -> unmap_vmap_area() # unmap memory here.
> -> write_lock(&vmlist_lock)
> remvoe vm_struct from list
> write_unlock(&vmlist_lock).
>==
>vread()
> -> read_lock(&vmlist_lock);
> get vm_struct -> do memcpy
> read_unlock(&vmlist_lock);
>==
I think this is a very good catch!
Your patch looks reasonable for me.
>
>Hmm, maybe not related to original bug but above order should be fixed.
>
>From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
>vmap area should be purged after vm_struct is removed from the list
>because vread/vwrite etc...believes the range is valid while it's on
>vm_struct list.
>
>Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
Aside, would you like to replace vmlist, a single list, with our
generic list API? :) Just as you did for kcore. Pls send it in
a seprate patch.
Thanks!
>---
> mm/vmalloc.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
>Index: linux-2.6.31-rc4/mm/vmalloc.c
>===================================================================
>--- linux-2.6.31-rc4.orig/mm/vmalloc.c
>+++ linux-2.6.31-rc4/mm/vmalloc.c
>@@ -1256,17 +1256,21 @@ struct vm_struct *remove_vm_area(const v
> if (va && va->flags & VM_VM_AREA) {
> struct vm_struct *vm = va->private;
> struct vm_struct *tmp, **p;
>-
>- vmap_debug_free_range(va->va_start, va->va_end);
>- free_unmap_vmap_area(va);
>- vm->size -= PAGE_SIZE;
>-
>+ /*
>+ * remove from list and disallow access to this vm_struct
>+ * before unmap. (address range confliction is maintained by
>+ * vmap.)
>+ */
> write_lock(&vmlist_lock);
> for (p = &vmlist; (tmp = *p) != vm; p = &tmp->next)
> ;
> *p = tmp->next;
> write_unlock(&vmlist_lock);
>
>+ vmap_debug_free_range(va->va_start, va->va_end);
>+ free_unmap_vmap_area(va);
>+ vm->size -= PAGE_SIZE;
>+
> return vm;
> }
> return NULL;
>
next prev parent reply other threads:[~2009-07-29 9:38 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 ` Amerigo Wang [this message]
2009-07-29 11:53 ` [RFC][PATCH 1/2] vmalloc: reorder unmap and removal entry 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
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=20090729094034.GF5856@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.