From: kanoj@kulten.engr.sgi.com (Kanoj Sarcar)
To: Neil Booth <NeilB@earthling.net>
Cc: linux-mm@kvack.org
Subject: Re: PATCH - bug in vfree
Date: Mon, 22 Feb 1999 12:31:12 -0800 [thread overview]
Message-ID: <9902221231.ZM2522@kulten.engr.sgi.com> (raw)
In-Reply-To: Neil Booth <NeilB@earthling.net> "PATCH - bug in vfree" (Feb 20, 8:46pm)
On Feb 20, 8:46pm, Neil Booth wrote:
> Subject: PATCH - bug in vfree
>
>
> Quick description:- vfree forgets to subtract the extra cushion page
> from the size of each virtual memory area stored in vmlist when it calls
> vmfree_area_pages. This means that only the vmalloc-requested size is
> allocated by vmalloc_area_pages, but the requested size PLUS the cushion
> page is freed by vmfree_area_pages.
>
> More deeply:- Close inspection of get_vm_area reveals that
> (intentionally?) it does NOT insist there be a cushion page behind a VMA
> that is placed in front of a previously-allocated VMA, it ONLY
> guarantees that a cushion page lies in front of newly-allocated VMAs.
> Thus two VMAs could be immediately adjacent without a cushion page, and
> coupled with the vfree bug means that vfree-ing the first VMA also frees
> the first page of the second VMA, with dire consequences.
>
> I have described this as clearly as I can, I hope it makes sense. Alan,
> this same bug also exists in 2.0.36.
>
> Neil.
>
> [ text/plain ] :
>
> --- linux/mm/vmalloc.c~ Sun Jan 24 19:21:06 1999
> +++ linux/mm/vmalloc.c Sat Feb 20 20:17:11 1999
> @@ -187,7 +187,7 @@
> for (p = &vmlist ; (tmp = *p) ; p = &tmp->next) {
> if (tmp->addr == addr) {
> *p = tmp->next;
> - vmfree_area_pages(VMALLOC_VMADDR(tmp->addr),
tmp->size);
> + vmfree_area_pages(VMALLOC_VMADDR(tmp->addr), tmp->size
- PAGE_SIZE);
> kfree(tmp);
> return;
> }
>-- End of excerpt from Neil Booth
On Feb 20, 9:14pm, Neil Booth wrote:
> Subject: Re: PATCH - bug in vfree
> Neil Booth wrote:
>
> > More deeply:- Close inspection of get_vm_area reveals that
> > (intentionally?) it does NOT insist there be a cushion page behind a VMA
> > that is placed in front of a previously-allocated VMA, it ONLY
> > guarantees that a cushion page lies in front of newly-allocated VMAs.
>
> Sorry, this is not correct (mistook < for <=). The bug report is
> correct, though.
>
> Neil.
Given that we agree that there is always one page between vm_structs,
the extra page freeing (in vfree) is probably inconsequential, given
that vmfree_area_pages/free_area_pmd/free_area_pte basically ignores
null ptes. But yes, I agree it would be nice to get the "bug" fixed
in vfree().
Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-02-22 20:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-20 11:46 PATCH - bug in vfree Neil Booth
1999-02-20 12:14 ` Neil Booth
1999-02-27 2:39 ` Neil Booth
1999-02-22 20:31 ` Kanoj Sarcar [this message]
1999-02-25 0:47 ` Andrea Arcangeli
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=9902221231.ZM2522@kulten.engr.sgi.com \
--to=kanoj@kulten.engr.sgi.com \
--cc=NeilB@earthling.net \
--cc=linux-mm@kvack.org \
/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.