From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 823C043C078 for ; Thu, 6 Aug 2026 16:59:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035597; cv=none; b=Vj6vGRL9UB0ZEgKox3aVS/iDtGaruimGxYCiAFpnK7YNiGPNzKeCZVKAXhXq9ZsXv2LKNi+n/R/nrVuEn21R7vBF8/iGRULB0vbai532mTWPgWlzdULYU9Zl1iq2OJ2elFwWippGXNKU666Y6Rq17AvNG5u/JUHq+Y/IvxOgVcY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786035597; c=relaxed/simple; bh=PhUfiLl4o8/gnM5dBdAr9/CI3mtr8neFPCeerCnHCbI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GDzXJwgVnvG0iWAjVPS2MeTyXsol29V009xZcrrqzQ2+UNGwGJIqFeNqOHvKQQxJsoCRg4IXsZJ9k7Y6urZjtw0HeeLz47yBeNrJcmPT+tfJX6m2JfP21noPYo/QxGG8fSj1fC5y/LWaayz/YJzhL+M5S7Hbc6qln72vAfoyUq8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iK9FazpK; arc=none smtp.client-ip=209.85.221.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iK9FazpK" Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-5c3a1d005c5so1364825e0c.1 for ; Thu, 06 Aug 2026 09:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786035594; x=1786640394; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a0eDfGNL18OJWRoQDXpl4mokl45SZAvTsQakbJs+ewI=; b=iK9FazpK4YT7CI/a0908Op2Wo+SMHFr5IcWGldEOkw0g0Vox3sVreDirnyg/dxtMU0 gW85+Bpx3hkC+xU/FrHIVnDFdW34dHo+HXI48f0DCxlSUo35WrRPSWEfAA+SYmnLbDXp Nu1eu9oWwpjwORQtH/uSf6dBIwGrxv/S8PiFdekbqIWvELMz9BzbWbNpucDj14fxow5F rSSmDu39oQkBjwLAMXw0Mt58OhYwU3U2/ncLkH6vX4c/P3i+IhbvliyCwiE0EkrFQZ1q pJrNTtApqq+hGpHlvo//W1F3z3wSZhUhfLkPdM8gA23YuGjr+u/1ip3JIFoaHJq8kQp9 T6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786035594; x=1786640394; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=a0eDfGNL18OJWRoQDXpl4mokl45SZAvTsQakbJs+ewI=; b=qILcURmIsVKwdhFkO9FAYYgf/SlMdMiXYfbpetPEviVDykoGC0+6Pbvt5srp7zizYu CNPKrcAJlSvmbKbkZYGlQ/1dUWoi7GB8zstI2HVp3iCJKoE85BLKK2VFBNR2+1B0noQE N8uAyClNwXb/Y+vGdq5s5nW8vx1RWRhRCbsgEv2OIzU3yLFgUdNTJJIKz9AofP9PZjNM oJDCKGdmzsKqm6w68nCy98QrmfbjKkPWQfJFpwvxxzKVePPE3wQDgJwYseCwJCeJLzOz rc1zBFPSHUoi2iBv10gode+w+foFdUKBawxYC4n0OhoeKpj3enuIMh6gqyYs0xS5rm46 ELqg== X-Forwarded-Encrypted: i=1; AHgh+RrjCA+PPsumv+eMxhL2IYq9DRhuoPRdk29t592meDcB8cacw4BcskfvtK8fJgIf+1QBOHnStDYP4CQP7Oo=@vger.kernel.org X-Gm-Message-State: AOJu0YzHwJ4meX1vgd2k/q2YrM2eayzQ5iivwNq39POTeTMhdla074dr vRl9wNgY3Deo2++k9BCOKzVzPu4Q1UyX47IXIjvdV/BsCnJdehvzSaPw X-Gm-Gg: AR+sD10ZlLAPn9NxvDiJMlMGtuJ5YPA5zkYB1/ubf/AbFoSWmVho2PZHCeHM9Z4B3D5 4S+lFWLFAK7mj65uTmFj2GbFMvzw2zvW974vV9+c1JnDidjmYk7QMBHQkNn4NRKZhxaRdhgNIL9 NUazElBMa8LsYutmM+c1KNYLuuisYyx/VJKprDJPdcQL3VPhpTWlS+OqJnJVKKmmyU7bUcjdHwS snETgxQtkW4LzpaMcyx6UkDa867NWxDzFYez++Jl0tbub9ZanZIFSI4m6jqREalD1AIT5yTLsgJ h3BkpEppZHHz/vFUA9FwFrxyn+Ov+2nA91dnZV9I5G7wzdHAffrqrTiNFbLQ1aU7FGKBdXbIM9n i/iXIvC0TSr0vRUmU1qMSOkLxL8rTjNZ/+fGT+zF1gNBRkbBIoXx2LpSJDimvietrxnrD7LxuGi Nfj4RZ+fP/GSvHKqxwhRclJ/h30+ZjJ5rMA7XSllCUKSs1b6FpW7mEp2NI7QGIt8esVYZPROQId E1MwfY= X-Received: by 2002:a05:6122:8b8d:b0:5bd:ecad:8f80 with SMTP id 71dfb90a1353d-5c3f9e68046mr593995e0c.2.1786035594156; Thu, 06 Aug 2026 09:59:54 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5c3d05c594fsm3706321e0c.8.2026.08.06.09.59.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 09:59:53 -0700 (PDT) From: Chao Shi To: Jan Kara , Christian Brauner , Alexander Viro , Matthew Wilcox , linux-fsdevel@vger.kernel.org Cc: Theodore Ts'o , Andreas Dilger , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Zhang Yi , Bob Copeland , Namjae Jeon , Sungjong Seo , Yuezhang Mo , OGAWA Hirofumi , Mark Fasheh , Joel Becker , Joseph Qi , Andreas Gruenbacher , linux-ext4@vger.kernel.org, ocfs2-devel@lists.linux.dev, gfs2@lists.linux.dev, linux-kernel@vger.kernel.org, Chao Shi , Weidong Zhu 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 Message-ID: <568e57d184da17041872fd4b498f31dd6259a4c1.1785951556.git.coshi036@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Signed-off-by: Chao Shi Reviewed-by: Jan Kara --- 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