public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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


  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