From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
To: Linux MM <linux-mm@kvack.org>
Subject: Bug in do_munmap (fwd)
Date: Wed, 3 Jun 1998 19:56:05 +0200 (MET DST) [thread overview]
Message-ID: <Pine.LNX.3.95.980603195556.3900B-100000@localhost> (raw)
---------- Forwarded message ----------
Date: Sun, 31 May 1998 21:40:14 +1700 (PDT)
From: Perry Harrington <pedward@sun4.apsoft.com>
To: Rik Van Riel <H.H.vanRiel@phys.uu.nl>
Subject: Bug in do_munmap
Rik,
After the PTE bug post to bugtraq last week, I've been investigating
this. There definitely appears to be a bug, where exactly, I'm unsure.
I've run the PTE killer under 2.1.95 and have confirmed that indeed
768 pages are allocated for the VMA. munmap is called for each mapping,
however zap_page_range doesn't appear to be freeing all the pages.
So, to summarize, I have confirmed that 768 pages are not freed, however
the code does call zap_page_range, which should free the PTEs associated
with that mapping.
I think I found the problem. In zap_page_range:
pgd_t * dir;
unsigned long end = address + size;
dir = pgd_offset(mm, address);
flush_cache_range(mm, end - size, end);
while (address < end) {
zap_pmd_range(dir, address, end - address);
address = (address + PGDIR_SIZE) & PGDIR_MASK;
dir++;
}
As you can see, dir is never freed. If you look at zap_pmd_range, dir
is used as a lookup point. dir is what's being left around after the
mmap. The reason that this isn't a system wide memory leak is because
the pages are freed when the process is reaped. Does this sound right?
--Perry
--
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\
next reply other threads:[~1998-06-03 19:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-06-03 17:56 Rik van Riel [this message]
1998-06-03 21:01 ` Bug in do_munmap (fwd) Benjamin C.R. LaHaise
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=Pine.LNX.3.95.980603195556.3900B-100000@localhost \
--to=h.h.vanriel@phys.uu.nl \
--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.