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:3.005 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site