mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Shi <coshi036@gmail.com>
To: Jan Kara <jack@suse.cz>, Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	linux-fsdevel@vger.kernel.org
Cc: Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Baokun Li <libaokun@linux.alibaba.com>,
	Ojaswin Mujoo <ojaswin@linux.ibm.com>,
	Ritesh Harjani <ritesh.list@gmail.com>,
	Zhang Yi <yi.zhang@huawei.com>,
	Zhang Yi <yi.zhang@huaweicloud.com>,
	Bob Copeland <me@bobcopeland.com>,
	Namjae Jeon <linkinjeon@kernel.org>,
	Sungjong Seo <sj1557.seo@samsung.com>,
	Yuezhang Mo <yuezhang.mo@sony.com>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	Joseph Qi <joseph.qi@linux.alibaba.com>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev,
	gfs2@lists.linux.dev, linux-kernel@vger.kernel.org,
	Chao Shi <coshi036@gmail.com>, Weidong Zhu <weizhu@fiu.edu>
Subject: [PATCH v2 13/21] ext4: check for a metadata write error with buffer_write_io_error()
Date: Thu,  6 Aug 2026 12:58:36 -0400	[thread overview]
Message-ID: <568e57d184da17041872fd4b498f31dd6259a4c1.1785951556.git.coshi036@gmail.com> (raw)
In-Reply-To: <cover.1785951556.git.coshi036@gmail.com>

Two places detect a failed metadata write by testing !buffer_uptodate()
after waiting for it.  That relies on the write completion handler clearing
BH_Uptodate on error, which this series removes: a buffer whose write
failed still holds the data the filesystem asked to be written, so
declaring it not up to date is wrong and makes callers re-read it.

ext4 already does this correctly for the superblock - see
ext4_commit_super(), which tests buffer_write_io_error() - so this brings
the other two into line.

In __ext4_handle_dirty_metadata() the old test also required BH_Req.
BH_Write_EIO implies it, so the pair collapses into one test.  The new test
is also strictly stronger than consuming sync_dirty_buffer()'s return
value, because it still fires when the buffer was written by background
writeback and that write hit an error, which sync_dirty_buffer() does not
report.

Note that the failing write does not clear BH_Write_EIO, so an unrepaired
itable block now reports on every subsequent sync of that inode rather than
only on the write that failed.  That is the intended behaviour, and matches
what ocfs2 has always done with this flag.

No behaviour change today - a failed write sets BH_Write_EIO and clears
BH_Uptodate together.  It stops being a no-op at the end of the series,
where the new test is the one that still works.

Acked-by: Weidong Zhu <weizhu@fiu.edu>
Signed-off-by: Chao Shi <coshi036@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
---
 fs/ext4/ext4_jbd2.c | 2 +-
 fs/ext4/mmp.c       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
index 02b066299164..f338d6e3c29f 100644
--- a/fs/ext4/ext4_jbd2.c
+++ b/fs/ext4/ext4_jbd2.c
@@ -413,7 +413,7 @@ int __ext4_handle_dirty_metadata(const char *where, unsigned int line,
 		}
 		if (inode && inode_needs_sync(inode)) {
 			sync_dirty_buffer(bh);
-			if (buffer_req(bh) && !buffer_uptodate(bh)) {
+			if (buffer_write_io_error(bh)) {
 				ext4_error_inode_err(inode, where, line,
 						     bh->b_blocknr, EIO,
 					"IO error syncing itable block");
diff --git a/fs/ext4/mmp.c b/fs/ext4/mmp.c
index 7ce361484b38..4b18ddef468d 100644
--- a/fs/ext4/mmp.c
+++ b/fs/ext4/mmp.c
@@ -49,7 +49,7 @@ static int write_mmp_block_thawed(struct super_block *sb,
 	bh_submit(bh, REQ_OP_WRITE | REQ_SYNC | REQ_META | REQ_PRIO,
 			bh_end_write);
 	wait_on_buffer(bh);
-	if (unlikely(!buffer_uptodate(bh)))
+	if (unlikely(buffer_write_io_error(bh)))
 		return -EIO;
 	return 0;
 }
-- 
2.43.0


  parent reply	other threads:[~2026-08-06 16:59 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 16:58 [PATCH v2 00/21] buffer: stop clearing BH_Uptodate when a write fails Chao Shi
2026-08-06 16:58 ` [PATCH v2 01/21] buffer_head: Remove b_page Chao Shi
2026-08-06 16:58 ` [PATCH v2 02/21] buffer: allow a buffer_head to point at memory outside the page cache Chao Shi
2026-08-06 16:58 ` [PATCH v2 03/21] jbd2: point the shadow buffer at the frozen data directly Chao Shi
2026-08-25 16:09   ` Jan Kara
2026-09-01  3:37   ` Joseph Qi
2026-09-01  4:19     ` Aithal, Srikanth
2026-09-01  9:40     ` Luca Weiss
2026-09-01 13:21     ` Jan Kara
2026-09-03 12:12     ` Venkat
2026-09-10 14:15       ` Bert Karwatzki
2026-09-10 15:24         ` Chris S
2026-09-10 15:10     ` Chris S
2026-08-06 16:58 ` [PATCH v2 04/21] buffer: read the folio's mapping directly in buffer_set_crypto_ctx() Chao Shi
2026-08-25 16:10   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 05/21] buffer: clear BH_Write_EIO when a buffer is forgotten Chao Shi
2026-08-06 16:58 ` [PATCH v2 06/21] buffer: discard BH_Write_EIO along with the rest of the buffer state Chao Shi
2026-08-06 16:58 ` [PATCH v2 07/21] buffer: detect metadata write errors with buffer_write_io_error() Chao Shi
2026-08-06 16:58 ` [PATCH v2 08/21] adfs: check for a directory write error " Chao Shi
2026-08-25 16:12   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 09/21] ext2: check for an xattr block " Chao Shi
2026-08-06 16:58 ` [PATCH v2 10/21] omfs: check for an inode " Chao Shi
2026-08-25 16:12   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 11/21] exfat: check for a directory " Chao Shi
2026-08-25 16:17   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 12/21] fat: check for a metadata " Chao Shi
2026-08-25 16:19   ` Jan Kara
2026-08-06 16:58 ` Chao Shi [this message]
2026-08-06 16:58 ` [PATCH v2 14/21] ocfs2: " Chao Shi
2026-08-06 16:58 ` [PATCH v2 15/21] ocfs2: check for a stale write error before reusing a metadata buffer Chao Shi
2026-08-06 16:58 ` [PATCH v2 16/21] gfs2: check for a metadata write error with buffer_write_io_error() Chao Shi
2026-08-25 17:06   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 17/21] jbd2: report journal write errors with BH_Write_EIO Chao Shi
2026-08-25 17:19   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 18/21] jbd2: say what jbd2_freeze_jh_data()'s assertion is actually checking Chao Shi
2026-08-25 17:18   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 19/21] ext4, jbd2: report fast commit write errors with BH_Write_EIO Chao Shi
2026-08-25 17:16   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 20/21] buffer: stop touching BH_Uptodate on write completion Chao Shi
2026-08-25 17:21   ` Jan Kara
2026-08-06 16:58 ` [PATCH v2 21/21] buffer: clear BH_Write_EIO when a write succeeds, not when one starts Chao Shi
2026-08-25 17:24   ` Jan Kara
2026-08-14 15:35 ` [PATCH v2 00/21] buffer: stop clearing BH_Uptodate when a write fails Chris S
2026-08-31  8:20 ` Christian Brauner

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=568e57d184da17041872fd4b498f31dd6259a4c1.1785951556.git.coshi036@gmail.com \
    --to=coshi036@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=agruenba@redhat.com \
    --cc=brauner@kernel.org \
    --cc=gfs2@lists.linux.dev \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=jack@suse.cz \
    --cc=jlbec@evilplan.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=libaokun@linux.alibaba.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=me@bobcopeland.com \
    --cc=ocfs2-devel@lists.linux.dev \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=sj1557.seo@samsung.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=weizhu@fiu.edu \
    --cc=willy@infradead.org \
    --cc=yi.zhang@huawei.com \
    --cc=yi.zhang@huaweicloud.com \
    --cc=yuezhang.mo@sony.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®