[lkml]   [2009]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] [13/16] HWPOISON: The high level memory error handler in the VM v3
On Tue, Jun 02, 2009 at 02:37:20PM +0200, Nick Piggin wrote:
> Because I don't see any difference (see my previous patch). I
> still don't know what it is supposed to be doing differently.
> So if you reinvent your own that looks close enough to truncate
> to warrant a comment to say /* this is close to truncate but
> not quite */, then yes I insist that you say exactly why it is
> not quite like truncate ;)

I will just delete that comment because it apparently causes so
much confusion.

> > > I'm suggesting that EIO is traditionally for when the data still
> > > dirty in pagecache and was not able to get back to backing
> > > store. Do you deny that?
> >
> > Yes. That is exactly the case when memory-failure triggers EIO
> >
> > Memory error on a dirty file mapped page.
> But it is no longer dirty, and the problem was not that the data
> was unable to be written back.

Sorry I don't understand. What do you mean with "no longer dirty"

Of course it's still dirty, just has to be discarded because it's

> > > And I think the application might try to handle the case of a
> > > page becoming corrupted differently. Do you deny that?
> >
> > You mean a clean file-mapped page? In this case there is no EIO,
> > memory-failure just drops the page and it is reloaded.
> >
> > If the page is dirty we trigger EIO which as you said above is the
> > right reaction.
> No I mean the difference between the case of dirty page unable to
> be written to backing sotre, and the case of dirty page becoming
> corrupted.

Nick, I have really a hard time following you here.

What exactly do you want?

A new errno? Or something else? If yes what precisely?

I currently don't see any sane way to report this to the application
through write(). That is because adding a new errno for something
is incredibly hard and often impossible, and that's certainly
the case here.

The application can detect it if it maps the
shared page and waits for a SIGBUS, but not through write().

But I doubt there will be really any apps that do anything differently
here anyways. A clever app could retry a few times if it still
has a copy of the data, but that might even make sense on normal
IO errors (e.g. on a SAN).

> > > OK, given the range of errors that APIs are defined to return,
> > > then maybe EIO is the best option. I don't suppose it is possible
> > > to expand them to return something else?
> >
> > Expand the syscalls to return other errnos on specific
> > kinds of IO error?
> >
> > Of course that's possible, but it has the problem that you
> > would need to fix all the applications that expect EIO for
> > IO error. The later I consider infeasible.
> They would presumably exit or do some default thing, which I
> think would be fine.

No it's not fine if they would handle EIO. e.g. consider
a sophisticated database which likely has sophisticated
IO error mechanisms too (e.g. only abort the current commit)


-- -- Speaking for myself only.

 \ /
  Last update: 2009-06-02 14:51    [W:0.243 / U:0.192 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site