From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Eric Sandeen <sandeen@redhat.com>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
Donald Douwsma <ddouwsma@redhat.com>,
Dave Chinner <dchinner@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] xfs: do not propagate ENODATA disk errors into xattr code
Date: Mon, 25 Aug 2025 00:55:06 -0700 [thread overview]
Message-ID: <aKwW2gEnQdIdDONk@infradead.org> (raw)
In-Reply-To: <20250822152137.GE7965@frogsfrogsfrogs>
On Fri, Aug 22, 2025 at 08:21:37AM -0700, Darrick J. Wong wrote:
> We only flag corruptions for these two error codes, but ENODATA from the
> block layer means "critical medium error". I take that to mean the
> media has permanently lost whatever was persisted there, right?
It can also be a write error. But yes, it's what EIO indidcates in
general. Which is why I really think we should be doing something like
the patch below. But as I don't have the time to fully shephed this
I'm not trying to block this hack, even if I think the issue will
continue to byte us in the future.
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index f9ef3b2a332a..0252faf038aa 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -1290,6 +1290,22 @@ xfs_bwrite(
return error;
}
+static int
+xfs_buf_bio_status(
+ struct bio *bio)
+{
+ switch (bio->bi_status) {
+ case BLK_STS_OK:
+ return 0;
+ case BLK_STS_NOSPC:
+ return -ENOSPC;
+ case BLK_STS_OFFLINE:
+ return -ENODEV;
+ default:
+ return -EIO;
+ }
+}
+
static void
xfs_buf_bio_end_io(
struct bio *bio)
@@ -1297,7 +1313,7 @@ xfs_buf_bio_end_io(
struct xfs_buf *bp = bio->bi_private;
if (bio->bi_status)
- xfs_buf_ioerror(bp, blk_status_to_errno(bio->bi_status));
+ xfs_buf_ioerror(bp, xfs_buf_bio_status(bio));
else if ((bp->b_flags & XBF_WRITE) && (bp->b_flags & XBF_ASYNC) &&
XFS_TEST_ERROR(false, bp->b_mount, XFS_ERRTAG_BUF_IOERROR))
xfs_buf_ioerror(bp, -EIO);
next prev parent reply other threads:[~2025-08-25 7:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 21:36 [PATCH] xfs: do not propagate ENODATA disk errors into xattr code Eric Sandeen
2025-08-22 15:21 ` Darrick J. Wong
2025-08-22 17:52 ` Eric Sandeen
2025-08-25 7:55 ` Christoph Hellwig [this message]
2025-08-25 15:31 ` Eric Sandeen
2025-08-25 15:34 ` Darrick J. Wong
2025-08-27 7:34 ` Christoph Hellwig
2025-08-27 15:56 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKwW2gEnQdIdDONk@infradead.org \
--to=hch@infradead.org \
--cc=dchinner@redhat.com \
--cc=ddouwsma@redhat.com \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.