From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794050391; b=V/jF1QoiCQZn8jMrPNeTViyWbb7Zjsizf8YMTtCkiUp6RchqSxlIAC9V+nEAGbWX9YzC KrhTZwdsXSg5aDXRhbg61lmnCUtD+Lh7zNSUwP2poK/ywj3iiZ1jEGDk8y+hPelWbwH6A l6m4+TiGSzqxUAMnqFGkcCcHdhFlsma+T5lz9hLLk2FzW/+heVp7kyOvu3/eTBF9Q5tYZ f0xNjnz+Gtd9yt7hQlB2ABdeS7M+7es2NF47Iz8sVSklmpypAqM2ARE9CcQvAJuJA61gN 079n1rAbZuCZL6G4ayEpIVjpsuJtxFXsRJ2bkq0+33s/pVol+LblE2pXj7fygF81nbg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794050391; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=T59scfimlSt/RdoCOGymTo9JVVO/T4NbfAE24OUrmk8=; b=OGOdHqPGAEvq7HvkGOaqjcRFi2es58hAdV4yiz1ncKw23W0Q7rZlY9YGHxZn3l2S+Nl5 IYwPYZue4yiiFkxjNkHP0EBp1MESQsMFRRcB3eAreFRiVIUJWuIBFyV1yTphAHVHpFnzQ TL7EVf3MnvWmSZXtzg9HX7MQxcGGIS6/3jc02e0xx3RtFixvZtDmpI3GREbJ9opz7Uc7k NtdVVX5HPen8PC85CTxWa08SQbbfOoJmbadlFGv53YGUNrxMMgzxUSBNup4Ezp5OAA1zz w0PzHZgDrfKyUBuocJisREUkGWpM3v+dtU8pYiP2UKaChaLLe5hsz9oahI37s6EHrdQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=c5k8czzB; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 500E4606A326 for ; Sat, 7 Nov 2026 11:19:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=c5k8czzB Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8F7B1F0089F; Sat, 7 Nov 2026 11:19:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794050391; bh=T59scfimlSt/RdoCOGymTo9JVVO/T4NbfAE24OUrmk8=; h=From:To:Cc:Subject:Date; b=c5k8czzBJdlwsrWYyDtKOmx/YMyrnDnSQwR9A2lKNJuUo50jFDyPWDoLh/ZFa1608 OqGn2CBGvfw+/m3miFBpx7P52sO5eTlO+7RD2TbtfcImyM9AEqhJjj93f1eSXv1ZKM F6YPwfc7QZjhxMrnGsnMGFq6RlHrh9mznbPtV8yJLhK18nWG7iEK+RzuOfUgQMX+dc YObQxaSz4B00IzH5TVKoqvH0s2h89sgLpE+QvV1Hi6LKBM2i9sKTwQ5hpkhPUGnMN8 Ju/qyHEJVtWLgEB+aGxtevjG3q2+2PqCe8/31YSbJE3REvdP8S4t8DqXdI9jfVOBQP JpRU9ivrh/Gag== From: Sasha Levin To: swinds24@gmail.com, jack@suse.cz, tytso@mit.edu Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] ext4: fix fast commit replay failing on a read-only mount" failed to apply to 5.10-stable tree Date: Sat, 7 Nov 2026 06:19:49 -0500 Message-ID: <20261107061949-failed-5.10-e1a881ea4674@kernel.org> X-Mailer: git-send-email 2.53.0 X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x e1a881ea4674876721cab97680d1d8308f90e9a4 # git commit -s git send-email --to '' --in-reply-to '20261107061949-failed-5.10-e1a881ea4674@kernel.org' --subject-prefix 'PATCH 5.10.y' 'HEAD^..' Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From e1a881ea4674876721cab97680d1d8308f90e9a4 Mon Sep 17 00:00:00 2001 From: Hsiu-Hsien Lee Date: Wed, 12 Aug 2026 12:43:53 +0800 Subject: [PATCH] ext4: fix fast commit replay failing on a read-only mount A filesystem with fast_commit that needs recovery cannot be mounted read-only: EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery WARNING: CPU: 22 PID: 5544 at fs/ext4/ext4_jbd2.c:73 ext4_journal_check_start __ext4_journal_start_sb __ext4_unlink ext4_fc_replay do_one_pass jbd2_journal_recover jbd2_journal_load __ext4_fill_super JBD2: journal recovery failed EXT4-fs (dm-0): error loading journal Fast commit replay runs ext4 metadata operations instead of writing blocks through the buffer cache: ext4_fc_replay_{unlink,link,create}() reach __ext4_unlink() and __ext4_link(), which start a handle. ext4_journal_check_start() returns -EROFS on a read-only sb, and as that is not -ENOENT it propagates out of jbd2_journal_recover() and kills the whole recovery. The EXT4_FC_REPLAY check that would hand out a no-journal handle sits after the sb_rdonly() test, so replay can never complete read-only. ext4_load_journal() has already promised that write access will be enabled during recovery, so make that true for the superblock as well: clear SB_RDONLY across jbd2_journal_load() when recovery is needed on a read-only mount and the devices are writable, as ext4_orphan_cleanup() does. Unlike ext4_handle_error(), which avoids SB_RDONLY because it would need s_umount, the sb here is still inside ext4_fill_super() and not published, so nothing can observe it. The failure is not clean either: the replay handlers passing a NULL handle (ext4_fc_replay_inode(), _add_range(), _del_range()) never hit ext4_journal_check_start() and do write, leaving a partially applied fast commit behind. Reproducer, where the unlink only ever reaches the fast commit area: mke2fs -q -F -t ext4 -O fast_commit -b 4096 /dev/sdb3 262144 mount /dev/sdb3 /mnt dd if=/dev/zero of=/mnt/victim bs=4k count=1 conv=fsync sync # victim now in a full commit rm /mnt/victim dd if=/dev/zero of=/mnt/trigger bs=4k count=1 conv=fsync mount -o ro /dev/sdb3 /mnt Without this patch that mount fails; with it recovery completes and victim is gone, i.e. the UNLINK record was really replayed. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@vger.kernel.org Signed-off-by: Hsiu-Hsien Lee Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260812044353.1018268-1-swinds24@gmail.com Signed-off-by: Theodore Ts'o --- fs/ext4/super.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index bca0dc87d0b7c..ab243a02a493c 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -6123,6 +6123,7 @@ static int ext4_load_journal(struct super_block *sb, int err = 0; int really_read_only; int journal_dev_ro; + bool enable_write = false; if (WARN_ON_ONCE(!ext4_has_feature_journal(sb))) return -EFSCORRUPTED; @@ -6179,6 +6180,7 @@ static int ext4_load_journal(struct super_block *sb, } ext4_msg(sb, KERN_INFO, "write access will " "be enabled during recovery"); + enable_write = true; } } @@ -6195,7 +6197,19 @@ static int ext4_load_journal(struct super_block *sb, if (save) memcpy(save, ((char *) es) + EXT4_S_ERR_START, EXT4_S_ERR_LEN); + /* + * Fast commit replay performs regular ext4 metadata updates + * (see ext4_fc_replay()) which refuse to run on a read-only + * superblock. We promised write access above, so make that + * true for the duration of the recovery, the same way + * ext4_orphan_cleanup() does. The superblock is not published + * yet, so nothing can observe the transient state. + */ + if (enable_write) + sb->s_flags &= ~SB_RDONLY; err = jbd2_journal_load(journal); + if (enable_write) + sb->s_flags |= SB_RDONLY; if (save && memcmp(((char *) es) + EXT4_S_ERR_START, save, EXT4_S_ERR_LEN)) { memcpy(((char *) es) + EXT4_S_ERR_START, -- 2.53.0