From: David Howells <dhowells@redhat.com>
To: uClinux development list <uclinux-dev@uclinux.org>
cc: linux-kernel@vger.kernel.org
Subject: bug in order>0 page allocations with !CONFIG_MMU
User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 04 Nov 2004 14:28:46 +0000
Message-ID: <19972.1099578526@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1353
Lines: 47


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/