All of lore.kernel.org
 help / color / mirror / Atom feed
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);

  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.