Re: [patch] fix for some ext2 race in 2.2.13

Stephen C. Tweedie (sct@redhat.com)
Mon, 8 Nov 1999 21:48:36 +0000 (GMT)


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/