Re: [PATCH 10/13: eCryptfs] Mmap operations

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 6 May 2006, Andrew Morton wrote:
> 
> Note that the pagefault handlers do still do a second readpage().  The
> comment implies that this is an open-coded attempt to recover from an I/O
> error.  I do recall that a year or so ago we discussed taking out that
> second readpage attempt, but Linus had good-sounding reasons for keeping
> it.  But I forget what they were.  Perhaps he can remind me?

All the non-readahead read paths - not just page faults, but certainly 
things like the generic file read routines - will do (at least they 
_should_ do) a "readpage()" if they find a page that is not up-to-date 
after they've gotten the lock.

That's basically just what the PG_uptodate flag means. If that flag isn't 
set, you need to ->readpage() the contents, whether you allocated the page 
yourself or not.

But nobody should ever do two readpages on their OWN. If readpage() fails, 
you should return -EIO (or whatever), and the page will be left 
not-up-to-date. But you do need to be able to accept the fact that a 
_previous_ read-page failed.

And yes, it happens in practice. Networked filesystems, for example. The 
previous person to try to read might have gotten a permission error. The 
same is true of any kind of security scheme where the "read()" checks may 
not match the "open()" security.

It's also true of read errors. You don't want to have the kernel re-try 
them forever, but on the other hand, you do NOT want to keep the page as 
an "error" forever without trying again. The read error could have been 
because the user had removed the media (or not closed the door properly), 
or anything else that the user could actually fix manually, and re-do the 
operation, and it would work.

Not all read errors are final. So we shouldn't consider them final.

		Linus