hidden assumptions in generic_file_write

[Muli Ben-Yehuda <mulix@mulix.org>]

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