Bug in do_munmap (fwd)

[Rik van Riel <H.H.vanRiel@phys.uu.nl>]

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