lkml.org 
[lkml]   [1999]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Q: generic_file_write sets PG_locked???


    On 24 Apr 1999, Eric W. Biederman wrote:
    >
    > However the current code has a nice little race.

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:0.023 / U:120.532 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site