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

Chris Mason
2009-04-29T11:30:57Z

On Wed, 2009-04-29 at 17:05 +0800, Wu Fengguang wrote:
> On Wed, Apr 29, 2009 at 04:36:55PM +0800, Andi Kleen wrote:
> > > > I'll have to read harder next week, the FS invalidatepage may expect
> > > > truncate to be the only caller.
> > >
> > > If direct de-dirty is hard for some pages, how about just ignore them?
> >
> > You mean just ignoring it for the pages where it is hard?
>
> Yes.
>
> > Yes that is what it is essentially doing right now. But at least
> > some dirty pages need to be handled because most user space
> > pages tend to be dirty.
>
> Sure. There are three types of dirty pages:
>
> A. now dirty, can be de-dirty in the current code
> B. now dirty, cannot be de-dirty
> C. now dirty and writeback, cannot be de-dirty
>
> I mean B and C can be handled in one single place - the block layer.
>
> If B is hard to be de-dirtied now, ignore them for now and they will
> eventually be going to IO and become C.
>
> > > There are the PG_writeback pages anyway. We can inject code to
> > > intercept them at the last stage of IO request dispatching.
> >
> > That would require adding error out code through all the file systems,
> > right?
>
> Not necessarily. The file systems deal with buffer head, extend map
> and bios, they normally won't touch the poisoned page content at all.
>

They often do when zeroing parts of the page that straddle i_size. At
least for btrfs its enough to change grab_cache_page and find_get_page
(and friends) to do the poison magic, along with the functions uses by
write_cache_pages.

-chris