Messages in this thread | | | Date | Thu, 23 Aug 2001 20:17:10 +0100 | From | Adrian Cox <> | Subject | Re: Filling holes in ext2 |
| |
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.
> If you change the error path in -ac's generic_file_write() thusly: > > - goto fail_write; > + status = -EFAULT; > + goto sync_failure; > > does it fix it?
No difference, as the write is to a hole in the middle of the file, and doesn't change i_size.
> Can you send the code you're using to demonstrate this?
The heart of it is this: fd = open(file, O_CREAT | O_TRUNC | O_RDWR, S_IRUSR | S_IWUSR); lseek(fd, 16385, SEEK_SET); write(fd, "x", 1); lseek(fd, 12345, SEEK_SET); write(fd, "y", 1); During the final write, I intervene with gdb to force the __copy_from_user() to fail. It should be possible to do something similar with a multi-threaded application where another thread modifies the VM, but I haven't actually built a real example.
Then I just take a look at the file with od.
[usermode:~] od -x /mnt/adrian/test 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0030000 0a79 0a79 0a79 0a79 0a79 0a79 0a79 0a79 * 0040000 7800 0040002
-- Adrian Cox http://www.humboldt.co.uk/
- 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/
| |