From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF5FE2DAFB5 for ; Tue, 30 Dec 2025 00:46:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767055608; cv=none; b=a46LEhxKEiWs9cOumTeKlelQy4LFm/Clpcu72bMHXZBuYWQgbotdaUBFpRNoTTClGjkgYpw/4lbMW5b8LlSv9pxtSEJFs3DjnKrJ/uVL5kTzvwkf2GvYLG1WUlqyhLGm48do4E+a4XtaVJG+JooA6qZc1AzkJoScBSQQB4yRSSY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767055608; c=relaxed/simple; bh=zC5/LzQ5aaS4gz4wVELElBHwMt5l9ZZ9Uy9NF+txWL0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Fqy8ja6Z90MqWIpUfeZMT9zkxUI7mDpSshjjLU672U+Qp3TT1CRTPID00Curf+27nXHUS0nuXsmZ2XHihJe5lFXgZX9pwlCk/udV8snmNsP5OUdiRBw6sBBeRojGcdofFPL8Xt/COKORi+YzcdX8NX8NuBp7d6zL68kqLJffTWI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s8NN3H/8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s8NN3H/8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 811DFC4CEF7; Tue, 30 Dec 2025 00:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767055608; bh=zC5/LzQ5aaS4gz4wVELElBHwMt5l9ZZ9Uy9NF+txWL0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s8NN3H/8dFh2VaNntp5GEfzTT8kWLQsdY05xOOHxjDL4s0q9UO4ghallTXyB1oTJ1 SRLjD8/+UNXXrWNbD3vBmP2SCtaKH3sBeD6DLNnpHmkI08rIx6H8re6IbVNbnpGfWU hyiB9a2aIcODd4fEhtQaphEs/zk5jZqbWY4kMhJrzns71K1EEnIMX0YfS6EJcM3gP8 EGU+7M9xg16qeIUZXwlevnay5wox6QuMq0G78bh1a/R8dxFCsqk83HurnH/mtJQ8U+ jKrsmgPCh9DwDxPFJufFjSkQKLk12tkmnGH6oenq/6dbn3PhD4AkCxaidBeZ/f9HsK /p/U8+CPFM5DQ== From: Sasha Levin To: stable@vger.kernel.org Cc: Ye Bin , Baokun Li , "Darrick J. Wong" , Jan Kara , Theodore Ts'o , stable@kernel.org, Sasha Levin Subject: [PATCH 6.1.y] jbd2: fix the inconsistency between checksum and data in memory for journal sb Date: Mon, 29 Dec 2025 19:46:45 -0500 Message-ID: <20251230004645.1895239-1-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <2025122934-exclude-sevenfold-d418@gregkh> References: <2025122934-exclude-sevenfold-d418@gregkh> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Ye Bin [ Upstream commit 6abfe107894af7e8ce3a2e120c619d81ee764ad5 ] Copying the file system while it is mounted as read-only results in a mount failure: [~]# mkfs.ext4 -F /dev/sdc [~]# mount /dev/sdc -o ro /mnt/test [~]# dd if=/dev/sdc of=/dev/sda bs=1M [~]# mount /dev/sda /mnt/test1 [ 1094.849826] JBD2: journal checksum error [ 1094.850927] EXT4-fs (sda): Could not load journal inode mount: mount /dev/sda on /mnt/test1 failed: Bad message The process described above is just an abstracted way I came up with to reproduce the issue. In the actual scenario, the file system was mounted read-only and then copied while it was still mounted. It was found that the mount operation failed. The user intended to verify the data or use it as a backup, and this action was performed during a version upgrade. Above issue may happen as follows: ext4_fill_super set_journal_csum_feature_set(sb) if (ext4_has_metadata_csum(sb)) incompat = JBD2_FEATURE_INCOMPAT_CSUM_V3; if (test_opt(sb, JOURNAL_CHECKSUM) jbd2_journal_set_features(sbi->s_journal, compat, 0, incompat); lock_buffer(journal->j_sb_buffer); sb->s_feature_incompat |= cpu_to_be32(incompat); //The data in the journal sb was modified, but the checksum was not updated, so the data remaining in memory has a mismatch between the data and the checksum. unlock_buffer(journal->j_sb_buffer); In this case, the journal sb copied over is in a state where the checksum and data are inconsistent, so mounting fails. To solve the above issue, update the checksum in memory after modifying the journal sb. Fixes: 4fd5ea43bc11 ("jbd2: checksum journal superblock") Signed-off-by: Ye Bin Reviewed-by: Baokun Li Reviewed-by: Darrick J. Wong Reviewed-by: Jan Kara Message-ID: <20251103010123.3753631-1-yebin@huaweicloud.com> Signed-off-by: Theodore Ts'o Cc: stable@kernel.org [ Changed jbd2_superblock_csum(sb) to jbd2_superblock_csum(journal, sb) ] Signed-off-by: Sasha Levin --- fs/jbd2/journal.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 41ab2dfd1ac2..4654a90a726a 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -2393,6 +2393,12 @@ int jbd2_journal_set_features(journal_t *journal, unsigned long compat, sb->s_feature_compat |= cpu_to_be32(compat); sb->s_feature_ro_compat |= cpu_to_be32(ro); sb->s_feature_incompat |= cpu_to_be32(incompat); + /* + * Update the checksum now so that it is valid even for read-only + * filesystems where jbd2_write_superblock() doesn't get called. + */ + if (jbd2_journal_has_csum_v2or3(journal)) + sb->s_checksum = jbd2_superblock_csum(journal, sb); unlock_buffer(journal->j_sb_buffer); journal->j_revoke_records_per_block = journal_revoke_records_per_block(journal); @@ -2423,9 +2429,17 @@ void jbd2_journal_clear_features(journal_t *journal, unsigned long compat, sb = journal->j_superblock; + lock_buffer(journal->j_sb_buffer); sb->s_feature_compat &= ~cpu_to_be32(compat); sb->s_feature_ro_compat &= ~cpu_to_be32(ro); sb->s_feature_incompat &= ~cpu_to_be32(incompat); + /* + * Update the checksum now so that it is valid even for read-only + * filesystems where jbd2_write_superblock() doesn't get called. + */ + if (jbd2_journal_has_csum_v2or3(journal)) + sb->s_checksum = jbd2_superblock_csum(journal, sb); + unlock_buffer(journal->j_sb_buffer); journal->j_revoke_records_per_block = journal_revoke_records_per_block(journal); } -- 2.51.0