Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 8 Nov 1999 21:48:36 +0000 (GMT) | Subject | Re: [patch] fix for some ext2 race in 2.2.13 |
| |
Hi,
On Sun, 7 Nov 1999 17:39:30 +0100 (CET), Andrea Arcangeli <andrea@suse.de> said:
> I spotted and fixed some subtle ext2 race in 2.2.13. > o in inode.c and balloc.c we are zeroing the block and then we are > marking the buffer uptodate and dirty. But while we write to the > buffer, the buffer can be locked and under read-IO from the > block_dev.c layer. So the underlying read may invalidate our zeros > with random on-disk data (random as the buffer was not allocated > previously). This is only a data corruption trouble and it has to > deal with truncates beyond the end of the file.
Nicely spotted. Can you see a mechanism which would actually cause this in real life, however, just from the filesystem? Data blocks cannot cause it: they only get loaded either asynchronously to the page cache (bypassing the buffer cache) or in response to partial writes, which at least in 2.2 are serialised with respect to truncate.
Indirect blocks probably can't cause it: fs/ext2/truncate.c is absoutely paranoid about being the only remaining user of the indirect blocks before calling bforget() on them.
That just leaves directory blocks. truncate does a busy wait (ugh, I know!) on those if they are found blocked, so we should again wait for completion before they ever get deallocated.
If there is something like a dump() or a raid resync reading the blocks in the background, though, then we can definitely fall foul of that here. However, a lot of the late-2.2 "access-beyond-end-of-block-dev" error reports do not involve such block device access.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |