From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 13 Feb 2013 08:18:45 -0800 From: Greg Kroah-Hartman To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Dave Chinner , Brian Foster , Ben Myers , CAI Qian Subject: Re: [ 68/89] xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end Message-ID: <20130213161845.GA20916@kroah.com> References: <20130201130207.444989281@linuxfoundation.org> <20130201130212.381996681@linuxfoundation.org> <511BB198.1080609@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511BB198.1080609@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: 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 > > > > 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