Bug in do_munmap (fwd)

Bug in do_munmap (fwd)

[Rik van Riel]

---------- 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. /\

Re: Bug in do_munmap (fwd)

[Benjamin C.R. LaHaise]

> I think I found the problem.  In zap_page_range:
...
> 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?

Even if this particular aspect of it is fixed, the user can still bring
down the system by doing an anon mmap of 1 page at each 4MB boundry...
The correct fix is to have some sort of ulimit on the size of page tables,
or to make page tables swappable (uh-oh, that's a toughie fraught with
races).

		-ben