Re: [PATCH] [13/16] POISON: The high level memory error handler inthe VM

[Chris Mason]

On Tue, 2009-04-07 at 17:10 +0200, Andi Kleen wrote:
> This patch adds the high level memory handler that poisons pages. 
> It is portable code and lives in mm/memory-failure.c

I think this is an important feature, thanks for doing all this work
Andi.

> Index: linux/mm/memory-failure.c
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ linux/mm/memory-failure.c	2009-04-07 16:39:39.000000000 +0200
> +
> +/*
> + * Clean (or cleaned) page cache page.
> + */
> +static int me_pagecache_clean(struct page *p)
> +{
> +	struct address_space *mapping;
> +
> +	if (PagePrivate(p))
> +		do_invalidatepage(p, 0);
> +	mapping = page_mapping(p);
> +	if (mapping) {
> +		if (!remove_mapping(mapping, p))
> +			return FAILED;
> +	}
> +	return RECOVERED;
> +}
> +
> +/*
> + * Dirty cache page page
> + * Issues: when the error hit a hole page the error is not properly
> + * propagated.
> + */
> +static int me_pagecache_dirty(struct page *p)
> +{
> +	struct address_space *mapping = page_mapping(p);
> +
> +	SetPageError(p);
> +	/* TBD: print more information about the file. */
> +	printk(KERN_ERR "MCE: Hardware memory corruption on dirty file page: write error\n");
> +	if (mapping) {
> +		/* CHECKME: does that report the error in all cases? */
> +		mapping_set_error(mapping, EIO);
> +	}
> +	if (PagePrivate(p)) {
> +		if (try_to_release_page(p, GFP_KERNEL)) {

So, try_to_release_page returns 1 when it works.  I know this only
because I have to read it every time to remember ;)

try_to_release_page is also very likely to fail if the page is dirty or
under writeback.  At the end of the day, we'll probably need a call into
the FS to tell it a given page isn't coming back, and to clean it at all
cost.

invalidatepage is close, but ext3/reiserfs will keep the buffer heads
and let the page->mapping go to null in an ugly data=ordered corner
case.  The buffer heads pin the page and it won't be freed until the IO
is done.

-chris


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