Re: [PATCH] ext4: Prevent massive fs corruption if verifying the block bitmap fails

[Theodore Ts'o <tytso@mit.edu>]

On Wed, Jul 17, 2013 at 12:09:00AM -0700, Darrick J. Wong wrote:
> 
> I have a question though -- ext4_init_inode_bitmap (and the block bitmap
> equivalent) contain code to detect a corrupt block group descriptor and "seal"
> it off by setting the inode/block's free counts to zero and writing 1s to the
> bitmap.  Does it make more sense to keep doing that, or to hook that up to this
> EXT4_MB_GRP_CORRUPT mechanism?

The only thing a I worry a bit about this what
ext4_init_inode_bitmap() is doing is if the block group descriptor
checksum is wrong, who's to say that the location of the inode bitmap
is correct?  Maybe it has been set to overlap with some valid data
block belonging to a directory, and by memset'ing the bh to zero and
then marking it up to date, when you try to read the directory, it
will get all zero's instead of the valid directory information.
(Fortunately the code in question isn't marking the bh dirty; if it
did, then it would guarantee the overwritting the directory or data
block in question, where as if it is just in the buffer cache marked
uptodate, the user might get lucky and the bh might get pushed out of
memory.)

What I would think is a better approach is to change the patch so that
we have bits indicating an invalid block bitmap and an invalid
inode/table bitmap, which disables block and inode allocations to that
block group, respectively.

We could just also set the inode/block's free counts to zero, but then
we would need to audit all of the codepaths where we decrement the
free count to make sure it never goes negative.  (We shold be doing
that already, though.)

					- Ted