>>>>> "EB" == Eric W Biederman <ebiederm+eric@ccr.net> writes:

    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/