Hi,
Looking at the following code of generic_file_write(), in 2.4, it
looks like there is a hidden assumption on the behavior of
prepare_write() and commit_write() about the behaviour of the file
system specific prepare_write() and commit_write() functions.
do {
.....
kaddr = kmap(page);
status = mapping->a_ops->prepare_write(file, page, offset, offset+bytes);
if (status)
goto sync_failure;
page_fault = __copy_from_user(kaddr+offset, buf, bytes);
flush_dcache_page(page);
status = mapping->a_ops->commit_write(file, page, offset, offset+bytes);
if (page_fault)
goto fail_write;
if (!status)
status = bytes;
if (status >= 0) {
written += status;
count -= status;
pos += status;
buf += status;
}
unlock:
kunmap(page);
/* Mark it unlocked again and drop the page.. */
SetPageReferenced(page);
UnlockPage(page);
page_cache_release(page);
if (status < 0)
break;
} while (count);
done:
......
Since the data is copied to the page after prepare_write() returns, it
seems that the assumption is that prepare_write() is synchronous and
the page was already read into memory in case it was not there.
Also, after commit_write(), the code immediately falls through unlock
which unlocks the page. Since a page is locked during IO, it seems
that commit_write() is synchronous and the page was already written
when it returns.
Can anyone clarify if these two assumptions are correct? if not, where
are we misinterpreting the code?
Regards,
Muli Ben-Yehuda,
Avi Teperman
-
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/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:18 EST