[PATCH RFC] xfs: remap block layer ENODATA read errors to EIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We had a report that a failing scsi disk was oopsing XFS when an xattr
read encountered a media error. This is because the media error returned
-ENODATA, which we map in xattr code to -ENOATTR and treat specially.

In this particular case, it looked like:

xfs_attr_leaf_get()
	error = xfs_attr_leaf_hasname(args, &bp);
	// here bp is NULL, error == -ENODATA from disk failure
	// but we define ENOATTR as ENODATA, so ...
	if (error == -ENOATTR)  {
		// whoops, surprise! bp is NULL, OOPS here
		xfs_trans_brelse(args->trans, bp);
		return error;
	} ...

To avoid whack-a-mole "test for null bp" or "which -ENODATA do we really
mean in this function?" throughout the xattr code, my first thought is
that we should simply map -ENODATA in lower level read functions back to
-EIO, which is unambiguous, even if we lose the nuance of the underlying
error code. (The block device probably already squawked.) Thoughts?

Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
---

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index f9ef3b2a332a..6ba57ccaa25f 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -747,6 +747,9 @@ xfs_buf_read_map(
 		/* bad CRC means corrupted metadata */
 		if (error == -EFSBADCRC)
 			error = -EFSCORRUPTED;
+		/* ENODATA == ENOATTR which confuses xattr layers */
+		if (error == -ENODATA)
+			error = -EIO;
 		return error;
 	}
 





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux