Messages in this thread | | | Date | Mon, 17 Feb 2003 17:00:00 +0200 | From | Muli Ben-Yehuda <> | Subject | hidden assumptions in generic_file_write |
| |
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/
| |