On 8/19/25 3:08 AM, 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. Ok, yeah, I had thought about just doing basically else return -EIO; as well. Though you and Dave seem to have different visions here, I do think that for XFS's purposes, a failed IO is -EIO unless we explicitly need something different. Anything finer grained or distributed to higher layers sounds like a bit of a maintenance and correctness nightmare, to me. -Eric
