lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: The INN/mmap bug

    OK, let's see. I've tried to describe what we have now (marking the
    bugs) + proposal that would give somewhat saner logics (in the end of
    posting). Comments are more than welcome.

    * life of the page is clearly divided in two parts - before it can
    be mapped to a user context and after that.
    * no read requests can be issued in the second stage, by that
    time page should be permanently up-to-date [ClearPageUptodate() in
    generic_file_write() is a bug]
    * buffer ring can be dropped only under the page lock.
    * on the first stage buffer ring can be dropped only if the page
    doesn't contain data that would be more recent than data in fs.
    * on the second stage buffer ring can be dropped if there is no IO
    scheduled or in progress [note: buffer_tied() might be handy, meaning
    "dirty or under IO"; i.e. when ll_rw_block() does or will need this bh]
    * we have several bh state components and the thing is a big,
    fscking mess. If we look at the areas outside of the page lock we have:

    1st stage, !uptodate, !mapped contents is either the same as on disk
    or it's a junk.
    1st stage, !uptodate, mapped failed attempt to read. contents may be
    the same as the last data on disk or
    it may be junk
    1st stage, uptodate, !mapped hole. Contents is all-zeroes. It may also
    be a result of failed attempt to map - we
    have no way to tell.
    1st stage, uptodate, mapped data. Same as on-disk or newer.
    2nd stage, !uptodate, !mapped contents is same or newer than on disk,
    mapping unknown. [Recipe for disaster,
    since the current code may try to read it;
    should be map-and-be-done-with-that]
    2nd stage, !uptodate, mapped failed attempt to read that should never
    happen. [Bug]
    2nd stage, uptodate, !mapped hole. Contents may be nonzero due to
    access via mmap(). May be a result of
    failed attempt to map [we don't handle
    such errors]
    2nd stage, uptodate, mapped data. Same as on disk or newer.

    Something should be done about that - aside of forced uptodate on
    the second stage we ought to flag the errors (possibly by BH_Error?)
    In __block_read_full_page() page being uptodate is a bug - we are
    going to lose data.
    Additionally, we have "tied by IO" state - can happen only for
    mapped uptodate bh.

    We seriously rely on the fact that on stage 1 we drop buffer ring
    only if the page has no data in need of write. We can't do that on stage 2
    (mmap() and dirtying the page from processes).
    Due to the above we can afford re-reading the data on stage 1.
    However, I'ld rather see a bitmap (PAGE_CACHE_SIZE/blocksize bits)
    describing what is not up-to-date. Then we could use it for deciding
    what should not be read.

    Comments?

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.025 / U:34.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site