lkml.org 
[lkml]   [2004]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectbug in order>0 page allocations with !CONFIG_MMU
Date

Hi,

I've found that this:

[mm/page_alloc.c]
static inline void set_page_refs(struct page *page, int order)
{
#ifdef CONFIG_MMU
set_page_count(page, 1);
#else
int i;

/*
* We need to reference all the pages for this order, otherwise if
* anyone accesses one of the pages with (get/put) it will be freed.
*/
for (i = 0; i < (1 << order); i++)
set_page_count(page+i, 1);
#endif /* CONFIG_MMU */
}

Causes problems if !CONFIG_MMU because __free_pages_ok()/free_pages_check()
reports a bad page on the second page when it comes time to free it:

Bad page state at __free_pages_ok (in process 'events/0', page c08132e0)
flags:0x20000000 mapping:00000000 mapcount:0 count:1

Why is doing this necessary at all? No one should be touching the individual
pages of a block allocation. The kernel should defend itself against
userspace trying to munmap part of a multipage mmap.

I think this should be:

static inline void set_page_refs(struct page *page, int order)
{
set_page_count(page, 1);
}

It seems to work for me. If no one disagrees, I'll give akpm a patch for this.

David
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.066 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site