I don't think so.
> Process A puts in a write request into the lands in the middle of the page.
> The page is initially uncached, so and since we didn't write
> PAGE_SIZE bytes we don't set PageUptodate.
> We delay the write.
Correct.
> Process B reads from the same page. So we call readpage (The page
> isn't uptodate). And overwrite what was in the page.
Wrong.
Any filesystem that does delayed writes _has_ to write them out before it
can read in the page again.
For NFS, look at nfs_readpage() in fs/nfs/read.c.
Again, the PG_locked bit is there to ensure serialization: inside
nfs_readpage() it guarantees that there can be no new write-requests
entering that page, so when we flush the old writes we know we've flushed
them all..
> Process C the kernel writer thread wakes up and writes the page
> to the backing store. But we have lost what Process A put there :(
>
> Since it is proveable that A came before B. (especially with a 30s
> write delay), and A didn't read what B wrote we have one problem.
Nope, PG_locked takes care of all that for us.
> And this still leaves it as an open question why keep the page locked
> around the call to updatepage. The only real function I can see is
> for a data coherency lock. . .
Look at the above: updatepage() implicitly adds a new write request to the
page. As such, PG_locked is there to ensure that it is synchronous wrt
anybody trying to read in the page.
Trust me, the locking is required, and it is minimal (apart from the fact
that I entirely agree on not needing to check PG_locked if PG_uptodate is
set, and we're only reading existing contents - either through mmap or
through generic_file_read. That's not really a locking issue, but an issue
of us sometimes unnecessarily waiting for a lock that we could just as
well just have ignored).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/