[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.156 / U:5.272 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site