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

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Aug 19, 2025 at 01:08:47AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 18, 2025 at 03:22:02PM -0500, Eric Sandeen wrote:
> > 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;
> 
> I think we need to stop passing random errors through here (same
> for the write side).  Unless we have an explicit handler (which we
> have for a tiny number of errors), passing random stuff we got through
> and which higher layers use for their own purpose will cause trouble.
> 
> Btw, your patch is timely as I've just seen something that probably
> is the same root cause when running XFS on a device with messed up
> PI, which is another of those cases where the block layer returns
> "odd" error codes.

Maybe xfs should translate bi_status into whatever error codes it wants
directly instead of relying on blk_status_to_errno, which can change in
subtle ways?

Though how many of those status codes actually need a different error?
BLK_STS_MEDIUM (ENODATA) and BLK_STS_NOTSUPP (EOPNOTSUPP) are the only
ones that look (to me) like they could be confused easily.

--D