lkml.org 
[lkml]   [2013]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
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@redhat.com>
> >
> > 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


\
 
 \ /
  Last update: 2013-02-13 18:21    [W:0.187 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site