From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (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 D6655339379 for ; Sat, 1 Aug 2026 22:01:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785621691; cv=none; b=r6GU5bXAWQkjWZbqExSsJAx5kO374EK7WT9lopRvulig8maZ+IDiVZl+Vk5RmON+AjK3lDTR8bMShsaOGW4WKO8jVLxncXQvyvbFaUGtmr63Rx572WnClZnhZZSuQIdZTUbigT/HSoji6MHHFdnC+w0j2Wj1vQtphthNCfZrfc4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785621691; c=relaxed/simple; bh=tojfuYvzfAMfs0bsJ/hEKkMgCSJ1prAxAJ+lK0XKzIo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sB9y1XCERTIX306bC/l1GGVQw1JLHZImojgq14O64cGb27Z59jMdtTVXBAk46ocFGuZ4aOexWMQfO9cupOq1xbvxEifLmwEkpLm+fvE/NfagOBlG7o/CQbHNjyiOOBKJkt71jRLW77oNR0mA+zSWcUPOVGbcpfny1wOxisl4F5g= 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=TYuH/kaP; arc=none smtp.client-ip=209.85.128.182 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="TYuH/kaP" Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-80cebd41372so32696007b3.3 for ; Sat, 01 Aug 2026 15:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785621687; x=1786226487; 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=S5d9GJjjHaj8KTJ0WAU1dmfHtrReZ7Fn8M10/pEoUFY=; b=TYuH/kaPqP7d3Q7Zz/nxr5ocNgCXUXsytaGpbw8XVlGTRRue8C5+ds4Pe7Tpr3sHIh Ezdxkj+G20pbV5xDuU60LWV7zhMUGZn3z0EnZhoVoLXXtQT7qj/b308VvG++6RsjEb2U whA8yDVvrOZzxlCZUQDDCV/rbn6w+clpklfhyn+XrjEVWJqu1xkps+7ncse+c+NjQC7s cU1iFfbfnVMW4EzHN562s7P0lFKwYphttpFHXtUywAzwB4hT3OnXwtWPrl4MwZnEPSyO QL9g51u6/yhB5U7T/7nJT2m+HMXX22Tzb6G1/Nh2GPn1yTtXlyTtUYas9n+bmaX9hq05 6Fow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785621687; x=1786226487; 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=S5d9GJjjHaj8KTJ0WAU1dmfHtrReZ7Fn8M10/pEoUFY=; b=Aa4GjvJVDjZpJpfybI2dkc28yX8n4VGao0hoIhHBxK8ZWsNJeI2upGYMm5C6aP3jQ9 DbcAf/NCEPiyF+IIPXml7RKt/f34+FRQfbKLHxofqWjz9RxOSZIPcPD2gEmTxNRvJsNd chzOBZg0g1UMclD+H5M0oIcaLPRwxh33VR91SumvnI2e6NxkZ1WSmdwz5QPSBOZLAtxF tbr+QFJ1BhEH1hsTZQnLTnU0MmPeYKhzeMFeZF5D31p9W8E9PS/ra3YgUL5uyQhPUmBY ar+IQvJRDOkZbLQu6jSqLdlqGO+jcYVaozBLPUeTlL0oR3Kk/O+0YocUw8sIu0auMczj wpHw== X-Forwarded-Encrypted: i=1; AHgh+RoUxZqX9djCdsQomba0FMnBE/+qZe3AgKS8mqQdTP1ypdOwKHfXKGhi6G/t4J7uHiRRfmg44Iu69csgUJI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzw62fmji4KKEgRU3jEPAE00/GAWSqUy+UpAInnXtjzna9wzRtJ cqsXcaJgYGt8zmDkHkkw2rWI9juOfHfXB9rQvb4YKs/UN8XAnUJhN4uk X-Gm-Gg: AR+sD115+Hrp5LEqGFCZ9l+Peo8srEwOnYYqSi4Ctu71B4vur3iLpG2c92k3pAS9ORc S2/6VtNLGgpsj2Y5zhURlMsYTEBN6jpeBI+I7b5jlviDtqAxd5Jyl/Zgn62LvouJVXa+oV/BIaC CfDaq/KdA0m7tvfuD9Q2rtFalXFT9BHRHDdI00exmUG6jUFXuSAF2bDwIeVbb9M71XnqazQlFVb bl7IZCofm3iXnw9/IwKfr4k4mmF+fiUoudTijfyxDeq8NxZeL8MYlZAa5oxVkUM0u8sWUojdBRt Q4RlTVWMbi8CfLd2WLhP8vHbBVl5eqbes2ypfkNJZB0C8njvqN/NyC7p23UIwfI34YsodFG0/OT sDlfCWrZFaUmLVI66SieLZHJT4p1PjI0gHaaypg86yP/tfw6h7a+VSoDSwBjY7neTjm6lTWJ31O wSBursebo16ITWJkLK5UlTLZixz9i6hnOzULavkR+Rct5Kci5HvhNe/KLcBpIEX8DsT40QLKWCv q0daps= X-Received: by 2002:a05:690c:48c3:b0:81e:d792:a019 with SMTP id 00721157ae682-81fd4a64bcbmr74354127b3.6.1785621686736; Sat, 01 Aug 2026 15:01:26 -0700 (PDT) Received: from syssplab.cs.fiu.edu (nat1.cs.fiu.edu. [131.94.134.89]) by smtp.gmail.com with ESMTPSA id 00721157ae682-81fcd0d6fbbsm29903767b3.25.2026.08.01.15.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Aug 2026 15:01:26 -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 , 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-karma-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Chao Shi Subject: [PATCH 12/19] ext4: check for a metadata write error with buffer_write_io_error() Date: Sat, 1 Aug 2026 18:00:56 -0400 Message-ID: <844d01d43111830a299346d0f3c6fddd62f22cc4.1785621505.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 BH_Write_EIO stays set until the buffer is written again, forgotten or invalidated, 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. Signed-off-by: Chao Shi --- 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