Re: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond thefilesystem end

From: Greg Kroah-Hartman
Date: Wed Feb 13 2013 - 11:18:54 EST


On Wed, Feb 13, 2013 at 04:30:32PM +0100, Paolo Bonzini wrote:
> Il 01/02/2013 14:08, Greg Kroah-Hartman ha scritto:
> > 3.7-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > commit eb178619f930fa2ba2348de332a1ff1c66a31424 upstream.
> >
> > When _xfs_buf_find is passed an out of range address, it will fail
> > to find a relevant struct xfs_perag and oops with a null
> > dereference. This can happen when trying to walk a filesystem with a
> > metadata inode that has a partially corrupted extent map (i.e. the
> > block number returned is corrupt, but is otherwise intact) and we
> > try to read from the corrupted block address.
> >
> > In this case, just fail the lookup. If it is readahead being issued,
> > it will simply not be done, but if it is real read that fails we
> > will get an error being reported. Ideally this case should result
> > in an EFSCORRUPTED error being reported, but we cannot return an
> > error through xfs_buf_read() or xfs_buf_get() so this lookup failure
> > may result in ENOMEM or EIO errors being reported instead.
>
> It looks like this breaks xfs_growfs. See
> http://bugzilla.redhat.com/show_bug.cgi?id=909602.

Ick, not good.

Dave, any thoughts here? Should I drop this from the 3.7-stable queue?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/