Re: [PATCH] generic debug pagealloc (-v2)

[Andrew Morton]

On Thu, 5 Mar 2009 23:59:27 +0900
Akinobu Mita <akinobu.mita@xxxxxxxxx> wrote:

> CONFIG_DEBUG_PAGEALLOC is now supported by x86, powerpc, sparc (64bit),
> and s390. This patch implements it for the rest of the architectures
> by filling the pages with poison byte patterns after free_pages() and
> verifying the poison patterns before alloc_pages().
> 
> This generic one cannot detect invalid read accesses and it can only
> detect invalid write accesses after a long delay. But it is a feasible way
> for nommu architectures.
> 
> ...
>
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +
> +static void poison_page(struct page *page)
> +{
> +	void *addr;
> +
> +	if (PageHighMem(page))
> +		return; /* i goofed */

heh.  A more complete comment would be needed here.

Also, as this is a kernel bug, perhaps some sort of runtime warning?

> +	page->poison = true;
> +	addr = page_address(page);
> +	memset(addr, PAGE_POISON, PAGE_SIZE);
> +}
> +
> +static void poison_pages(struct page *page, int n)
> +{
> +	int i;
> +
> +	for (i = 0; i < n; i++)
> +		poison_page(page + i);
> +}
> +
> +static void check_poison_mem(unsigned char *mem, size_t bytes)
> +{
> +	unsigned char *start;
> +	unsigned char *end;
> +
> +	for (start = mem; start < mem + bytes; start++) {
> +		if (*start != PAGE_POISON)
> +			break;
> +	}
> +	if (start == mem + bytes)
> +		return;
> +
> +	for (end = mem + bytes - 1; end > start; end--) {
> +		if (*end != PAGE_POISON)
> +			break;
> +	}
> +	printk(KERN_ERR "Page corruption: %p-%p\n", start, end);
> +	print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, start,
> +			end - start + 1, 1);
> +}
> +
> +static void unpoison_page(struct page *page)
> +{
> +	void *addr;
> +

Shouldn't we check PageHighmem() here also?

> +	if (!page->poison)
> +		return;
> +
> +	addr = page_address(page);
> +	check_poison_mem(addr, PAGE_SIZE);
> +	page->poison = false;
> +}
> +

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