EB> However the current code has a nice little race. Process A
EB> puts in a write request into the lands in the middle of the
EB> page.
EB> The page is initially uncached, so and since we didn't
EB> write PAGE_SIZE bytes we don't set PageUptodate. We delay
EB> the write.
EB> Process B reads from the same page. So we call readpage (The
EB> page
EB> isn't uptodate). And overwrite what was in the page.
EB> Process C the kernel writer thread wakes up and writes the
EB> page
EB> to the backing store. But we have lost what Process A put
EB> there :(
No. This doesn't happen because we make a call to nfs_wb_page
immediately after we've grabbed the page lock in nfs_readpage. This is
what assures write + read serialization for asynchronous writebacks.
(The page lock assures you don't start any new writes).
EB> And this still leaves it as an open question why keep the page
EB> locked around the call to updatepage. The only real function
EB> I can see is for a data coherency lock. . .
We want to serialize the case of write + write too. As I said earlier
in this thread, you cannot assume that either of 2 different processes
really have write permission even if the attributes seem to indicate
that they do. Ugly: but that's what a stateless protocol means...
Cheers,
Trond
-
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/