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

[Andi Kleen]

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

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

> 
> Some perceivable problems and solutions are
> 1) the intercepting overheads could be costly => inject code at runtime.
> 2) there are cases that the dirty page could be copied for IO:

At some point we should probably add poison checks before these operations
yes. At least for read it should be the same code path as EIO --
you have to check PG_error anyways  (or at least you ought to)
The main difference is that for write you have to check it too.

>    2.1) jbd2 has two copy-out cases => should be rare. just ignore them?
>      2.1.1) do_get_write_access(): buffer sits in two active commits
>      2.1.2) jbd2_journal_write_metadata_buffer(): buffer happens to start
>             with JBD2_MAGIC_NUMBER
>    2.2) btrfs have to read page for compress/encryption
>      Chris: is btrfs_zlib_compress_pages() a good place for detecting
>      poison pages? Or is it necessary at all for btrfs?(ie. it's
>      already relatively easy to de-dirty btrfs pages.)

I think btrfs' IO error handling is not very great right now. But once
it matures i hope poison pages can be handled in the same way as
regular IO errors.

>    2.3) maybe more cases...

Undoubtedly. Goal is just to handle the common cases that cover a lot 
of memory. This will never be 100%.

-Andi
-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only.
--
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/