From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Fix for for memory leak in IA32 mmap
Date: Tue, 05 Mar 2002 17:34:37 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590701905223@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905222@msgid-missing>
>>>>> On Tue, 5 Mar 2002 08:13:01 -0700, Don Dugger <n0ano@n0ano.com> said:
Don> David- Here is a patch against `linux-2.4.17-ia64-011226.diff'
Don> that fixes a memory leak with the IA32 `mmap'/`munmap' calls.
Don> The problem occurs when a non-fixed `mmap' allocates a range
Don> that ends in the middle of a page.
Nasty. You're talking about a _virtual_ address space leak, right? Do
you know the exact sequence of events that causes application failure?
Don> To handle problems with
Don> fixed requests the `munmap' call rounds down the the area
Don> freed, causing the memory leak. The only solution I can think
Don> of to deal with this is to create a list of the allocated
Don> starting addresses for all non-fixed `mmap' requests. `munmap'
Don> then checks this list and, if it finds a match, rounds the
Don> request size up rather than down.
It seems to me what we really want to do is keep track of partially
mapped pages. I think we'd need a bitmask showing which ia32 pages
have been mapped in an ia64 page. Say, a 16KB page whose first 4KB
have been mapped would be represented as:
ia32 page:
0 1 2 3
1 0 0 0
now, if someone maps the 3rd 4KB page, you'd get:
ia32 page:
0 1 2 3
1 0 1 0
and so on. The underlying ia64 page would then have to be freed
whenever the bitmask becomes empty.
--david
next prev parent reply other threads:[~2002-03-05 17:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-05 15:13 [Linux-ia64] Fix for for memory leak in IA32 mmap Don Dugger
2002-03-05 17:34 ` David Mosberger [this message]
2002-03-05 17:46 ` Don Dugger
2002-03-05 18:59 ` David Mosberger
2002-03-05 19:44 ` Luck, Tony
2002-03-05 20:06 ` n0ano
2002-03-05 20:09 ` David Mosberger
2002-03-05 21:49 ` Luck, Tony
2002-03-05 22:18 ` n0ano
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=marc-linux-ia64-105590701905223@msgid-missing \
--to=davidm@napali.hpl.hp.com \
--cc=linux-ia64@vger.kernel.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