* 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).