[lkml]   [2003]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH linux-2.6.1-rc1-mm1] filemap_fdatawait.patch
    Daniel McNeil <> wrote:
    > The other potential race in filemap_fdatawait() was that it
    > removed the page from the locked list while waiting for a writeback
    > and if there was a 2nd filemap_fdatawait() running on another cpu,
    > it would not wait for the page being written since it would never see
    > it on the list.

    That would only happen if one thread or the other was not running under
    i_sem. The only path I see doing that is in generic_file_direct_IO()?

    > + /*
    > + * If the page is locked, it might be in process of being
    > + * setup for writeback but without PG_writeback set
    > + * and with PG_dirty cleared.
    > + * (PG_dirty is cleared BEFORE PG_writeback is set)
    > + * So, wait for the PG_locked to clear, then start over.
    > + */
    > + if (PageLocked(page)) {
    > + page_cache_get(page);
    > + spin_unlock(&mapping->page_lock);
    > + wait_on_page_locked(page);
    > + page_cache_release(page);
    > + goto restart;
    > + }

    Why is this a problem which needs addressing here? If some other thread is
    in the process of starting I/O against this page then the page must have
    been clean when this thread ran filemap_fdatawrite()?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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