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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
