summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_ioctl.h
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2013-01-21 23:53:52 +1100
committerBen Myers <bpm@sgi.com>2013-01-24 11:06:41 -0600
commit10616b806d1d7835b1d23b8d75ef638f92cb98b6 (patch)
treefd8b03f594e7996624c156d792652249a5db491a /fs/xfs/xfs_ioctl.h
parent003fd6c8be14a348c56cb1d171605ab13fca906f (diff)
downloadop-kernel-dev-10616b806d1d7835b1d23b8d75ef638f92cb98b6.zip
op-kernel-dev-10616b806d1d7835b1d23b8d75ef638f92cb98b6.tar.gz
xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
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. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Ben Myers <bpm@sgi.com> Signed-off-by: Ben Myers <bpm@sgi.com>
Diffstat (limited to 'fs/xfs/xfs_ioctl.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud