* Re: [PATCH] [13/16] HWPOISON: The high level memory error handler in the VM v5
[not found] ` <20090603184648.2E2131D028F@basil.firstfloor.org>
@ 2009-06-09 9:51 ` Nick Piggin
2009-06-09 11:14 ` Nick Piggin
0 siblings, 1 reply; 2+ messages in thread
From: Nick Piggin @ 2009-06-09 9:51 UTC (permalink / raw)
To: Andi Kleen
Cc: hugh.dickins, riel, chris.mason, akpm, linux-kernel, linux-mm,
fengguang.wu, linux-fsdevel
On Wed, Jun 03, 2009 at 08:46:47PM +0200, Andi Kleen wrote:
> +static int me_pagecache_clean(struct page *p, unsigned long pfn)
> +{
> + struct address_space *mapping;
> +
> + if (!isolate_lru_page(p))
> + page_cache_release(p);
> +
> + /*
> + * Now truncate the page in the page cache. This is really
> + * more like a "temporary hole punch"
> + * Don't do this for block devices when someone else
> + * has a reference, because it could be file system metadata
> + * and that's not safe to truncate.
> + */
> + mapping = page_mapping(p);
> + if (mapping && S_ISBLK(mapping->host->i_mode) && page_count(p) > 1) {
> + printk(KERN_ERR
> + "MCE %#lx: page looks like a unsupported file system metadata page\n",
> + pfn);
> + return FAILED;
> + }
page_count check is racy. Hmm, S_ISBLK should handle xfs's private mapping.
AFAIK btrfs has a similar private mapping but a quick grep does not show
up S_IFBLK anywhere, so I don't know what the situation is there.
Unfortunately though, the linear mapping is not the only metadata mapping
a filesystem might have. Many work on directories in seperate mappings
(ext2, for example, which is where I first looked and will still oops with
your check).
Also, others may have other interesting inodes they use for metadata. Do
any of them go through the pagecache? I dont know. The ext3 journal,
for example? How does that work?
Unfortunately I don't know a good way to detect regular data mappings
easily. Ccing linux-fsdevel. Until that is worked out, you'd need to
use the safe pagecache invalidate rather than unsafe truncate.
> + if (mapping) {
> + truncate_inode_page(mapping, p);
> + if (page_has_private(p) && !try_to_release_page(p, GFP_NOIO)) {
> + pr_debug(KERN_ERR "MCE %#lx: failed to release buffers\n",
> + pfn);
> + return FAILED;
> + }
> + }
> + return RECOVERED;
> +}
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] [13/16] HWPOISON: The high level memory error handler in the VM v5
2009-06-09 9:51 ` [PATCH] [13/16] HWPOISON: The high level memory error handler in the VM v5 Nick Piggin
@ 2009-06-09 11:14 ` Nick Piggin
0 siblings, 0 replies; 2+ messages in thread
From: Nick Piggin @ 2009-06-09 11:14 UTC (permalink / raw)
To: Andi Kleen
Cc: hugh.dickins, riel, chris.mason, akpm, linux-kernel, linux-mm,
fengguang.wu, linux-fsdevel
On Tue, Jun 09, 2009 at 11:51:55AM +0200, Nick Piggin wrote:
> On Wed, Jun 03, 2009 at 08:46:47PM +0200, Andi Kleen wrote:
> > +static int me_pagecache_clean(struct page *p, unsigned long pfn)
> > +{
> > + struct address_space *mapping;
> > +
> > + if (!isolate_lru_page(p))
> > + page_cache_release(p);
> > +
> > + /*
> > + * Now truncate the page in the page cache. This is really
> > + * more like a "temporary hole punch"
> > + * Don't do this for block devices when someone else
> > + * has a reference, because it could be file system metadata
> > + * and that's not safe to truncate.
> > + */
> > + mapping = page_mapping(p);
> > + if (mapping && S_ISBLK(mapping->host->i_mode) && page_count(p) > 1) {
> > + printk(KERN_ERR
> > + "MCE %#lx: page looks like a unsupported file system metadata page\n",
> > + pfn);
> > + return FAILED;
> > + }
>
> page_count check is racy. Hmm, S_ISBLK should handle xfs's private mapping.
> AFAIK btrfs has a similar private mapping but a quick grep does not show
> up S_IFBLK anywhere, so I don't know what the situation is there.
>
> Unfortunately though, the linear mapping is not the only metadata mapping
> a filesystem might have. Many work on directories in seperate mappings
> (ext2, for example, which is where I first looked and will still oops with
> your check).
>
> Also, others may have other interesting inodes they use for metadata. Do
> any of them go through the pagecache? I dont know. The ext3 journal,
> for example? How does that work?
>
> Unfortunately I don't know a good way to detect regular data mappings
> easily. Ccing linux-fsdevel. Until that is worked out, you'd need to
> use the safe pagecache invalidate rather than unsafe truncate.
Maybe just testing S_ISREG would be better. Definitely safer than
ISBLK.
Note that for !ISREG files, then you can still attempt the
non-destructive invalidate (after extracting a suitable function
similarly to the truncate one). Most likely the fs is not using
the page right now, so it should give bit more coverage.
I still don't exactly know about, say, ext3 journal. Probably
it doesn't use pagecache anyway. Do any other filesystems do
crazy things with S_ISREG files? They probably deserve to oops
if they do ;)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-06-09 11:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20090603846.816684333@firstfloor.org>
[not found] ` <20090603184648.2E2131D028F@basil.firstfloor.org>
2009-06-09 9:51 ` [PATCH] [13/16] HWPOISON: The high level memory error handler in the VM v5 Nick Piggin
2009-06-09 11:14 ` Nick Piggin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).