Duane Griffin wrote: > While freeing indirect blocks we attach a journal head to the parent buffer > head, free the blocks, then journal the parent. If the indirect block list > is corrupted and points to the parent the journal head will be detached > when the block is cleared, causing an OOPS. > > Check for that explicitly and handle it gracefully. > > This patch fixes the third case (image hdb.20000057.nullderef.gz) > reported in http://bugzilla.kernel.org/show_bug.cgi?id=10882. > > Signed-off-by: Duane Griffin <duaneg@xxxxxxxxx> > --- > > diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c > index 6ae4ecf..8019bf2 100644 > --- a/fs/ext3/inode.c > +++ b/fs/ext3/inode.c > @@ -2127,7 +2127,20 @@ static void ext3_free_data(handle_t *handle, struct inode *inode, > > if (this_bh) { > BUFFER_TRACE(this_bh, "call ext3_journal_dirty_metadata"); > - ext3_journal_dirty_metadata(handle, this_bh); > + > + /* > + * The buffer head should have an attached journal head at this > + * point. However, if the data is corrupted and an indirect > + * block pointed to itself, it would have been detached when > + * the block was cleared. Check for this instead of OOPSing. > + */ > + if (bh2jh(this_bh)) Should it also (or only) be checking for buffer_jbd rather than testing bh2jh which is just shorthand for "is b_private non-null?" Also maybe I should know this intuitively by now, but what is the path where b_private / BH_JBD got cleared on this corrupted image? Thanks, -Eric > + ext3_journal_dirty_metadata(handle, this_bh); > + else > + ext3_error(inode->i_sb, "ext3_free_data", > + "circular indirect block detected, " > + "inode=%lu, block="E3FSBLK, > + inode->i_ino, this_bh->b_blocknr); > } > } > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
