Messages in this thread | | | Date | Wed, 31 Dec 2003 15:42:39 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH linux-2.6.1-rc1-mm1] filemap_fdatawait.patch |
| |
Daniel McNeil <daniel@osdl.org> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |