Adrian Cox wrote:
>
> Andrew Morton wrote:
>
> > generic_file_write() will mark the page not up-to-date in this case.
> > I wonder what's actually going on? Perhaps the fact that we've
> > instantiated a block in ext2 outside i_size?
>
> The problem is that the on-disk metadata now says that that disk block
> is part of the file. So as the page is not up-to-date, the next read
> operation will go to the disk and fetch that block of garbage into the
> page cache.
>
Ah. Now I'm with you. Yes, we need a better cleanup facility
to handle this.
We can sort-of fudge it with commit_write():
--- linux-2.4.8-ac9/mm/filemap.c Wed Aug 22 10:57:47 2001
+++ ac/mm/filemap.c Thu Aug 23 12:33:50 2001
@@ -2674,8 +2674,9 @@ generic_file_write(struct file *file,con
status = __copy_from_user(kaddr+offset, buf, bytes);
flush_dcache_page(page);
if (status) {
- if (mapping->a_ops->abort_write)
- mapping->a_ops->abort_write(file, page);
+ /* Zero the disk blocks so we don't expose stale data mid-file */
+ memset(kaddr + offset, 0, bytes);
+ mapping->a_ops->commit_write(file, page, offset, offset+bytes);
goto fail_write;
}
status = mapping->a_ops->commit_write(file, page, offset, offset+bytes);
@@ -2720,7 +2721,6 @@ out:
fail_write:
status = -EFAULT;
ClearPageUptodate(page);
- kunmap(page);
goto unlock;
sync_failure:
UnlockPage(page);
Which is OK for mid-file blocks, but will cause i_size to be extended
at eof, which probably isn't too bad. Needs more thought.
-
-
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 : Thu Aug 23 2001 - 21:01:01 EST