Re: fix iounmap and a pageattr memleak (x86 and x86-64)
From: Jason Baron
Date: Tue Nov 02 2004 - 17:45:36 EST
On Tue, 2 Nov 2004, Dave Hansen wrote:
> This patch:
> > From: Andrea Arcangeli <andrea@xxxxxxxxxx>
> > - fix silent memleak in the pageattr code that I found while searching
> > for the bug Andi fixed in the second patch below (basically reference
> > counting in split page was done on the pmd instead of the pte).
> > - Part of this patch is also needed to make the above work on x86 (otherwise
> > one of my new above BUGS() will trigger signalling the fact a bug was
> > there). The below patch creates a subtle dependency that (_PAGE_PCD << 24)
> > must not be zero. It's not the cleanest thing ever, but since it's an
> > hardware bitflag I doubt it's going to break.
> > Signed-off-by: Andi Kleen <ak@xxxxxxx>
> > Signed-off-by: Andrea Arcangeli <andrea@xxxxxxxxxx>
> > Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
> > ---
> > 25-akpm/arch/i386/mm/ioremap.c | 4 ++--
> > 25-akpm/arch/i386/mm/pageattr.c | 13 +++++++------
> > 25-akpm/arch/x86_64/mm/ioremap.c | 14 +++++++-------
> > 25-akpm/arch/x86_64/mm/pageattr.c | 23 ++++++++++++++---------
> > 4 files changed, 30 insertions(+), 24 deletions(-)
> is hitting this BUG() during bootup:
> /* memleak and potential failed 2M page regeneration */
> in 2.6.10-rc1-mm2.
I've seen the page_count being -1 (not sure why), for a number of pages in
the identity mapped region...So the BUG() on 0 doesn't seem valid to me.
Also, in order to tell if the pages should be merged back to create a huge
page, i don't see how the patch differentiates b/w pages that were split
and those that weren't simply based on the page_count....
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/