This patch fixes the upstream bug# 14286. When the address of an extent
corresponding to a valid block is corrupted, a -EIO should be reported instead
of a BUG(). This situation would not normally not occur. If however it does,
then the system should not panic directly but depending on the mount time options
appropriate action should be taken. If the mount options so permit, the I/O
should be gracefully aborted by returning a -EIO.
Signed-off-by: Surbhi Palande <surbhi.palande@xxxxxxxxxxxxx>
---
fs/ext4/extents.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 3a7928f..d59aa12 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3189,8 +3189,17 @@ int ext4_ext_get_blocks(handle_t *handle, struct inode *inode,
* consistent leaf must not be empty;
* this situation is possible, though, _during_ tree modification;
* this is why assert can't be put in ext4_ext_find_extent()
+ *
+ * We don't want to panic in this case, try and abort I/O gracefully
*/
- BUG_ON(path[depth].p_ext == NULL && depth != 0);
+ if (path[depth].p_ext == NULL && depth != 0) {
+ err = -EIO;
+ ext4_error(inode->i_sb, __func__,
+ "bad extent address "
+ "inode: %lu, iblock: %d, depth: %d",
+ inode->i_ino, iblock, depth);
+ goto out2;
+ }
eh = path[depth].p_hdr;
ex = path[depth].p_ext;
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
