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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox