Messages in this thread | | | Date | Wed, 3 Nov 2004 02:40:32 +0100 | From | Andrea Arcangeli <> | Subject | Re: fix iounmap and a pageattr memleak (x86 and x86-64) |
| |
On Tue, Nov 02, 2004 at 03:04:26PM -0800, Andrew Morton wrote: > Dave Hansen <haveblue@us.ibm.com> wrote: > > > > Andrea Arcangeli wrote: > > > Still I recommend investigating _why_ debug_pagealloc is violating the > > > API. It might not be necessary to wait for the pageattr universal > > > feature to make DEBUG_PAGEALLOC work safe. > > > > This makes the DEBUG_PAGEALLOC stuff symmetric enough to boot for me, > > and it's pretty damn simple. Any ideas for doing this without bloating > > 'struct page', even in the debugging case? > > You could use a bit from page->flags. But CONFIG_DEBUG_PAGEALLOC uses so > much additional memory nobody would notice anyway. > > hm. Or maybe page->mapcount is available on these pages.
"page < highmem_start_page" would be equivalent to page->mapped == 1.
I'll try to reproduce the problem, frankly I wondered how DEBUG_PAGEALLOC could ever work with the current pageattr code that is far from be usable outside a single device driver that owns the physical region (then I thought DEBUG_PAGEALLOC perhaps was in an unusable state like dead code). The current change_page_attr is basically only for symmetric use via ioremap_nocache or AGP explicit code, that _owns_ the region by registering in resource.c. Attempting to use the current restrictive API in random page resources not registared and owned by the caller, may not even be fixable without creating an universal API. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |