All of lore.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 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.