All of lore.kernel.org
 help / color / mirror / Atom feed
From: yebin <yebin@huaweicloud.com>
To: Zhang Yi <yi.zhang@huaweicloud.com>, linux-ext4@vger.kernel.org
Cc: jack@suse.cz, tytso@mit.edu, adilger.kernel@dilger.ca
Subject: Re: [PATCH] jbd2: fix the inconsistency between checksum and data in memory for journal sb
Date: Wed, 29 Oct 2025 19:44:54 +0800	[thread overview]
Message-ID: <6901FE36.6030404@huaweicloud.com> (raw)
In-Reply-To: <cf167bfa-fb1e-40fa-81e6-071dab2442c0@huaweicloud.com>



On 2025/10/29 16:45, Zhang Yi wrote:
> Hi Bin!
>
> On 10/28/2025 2:47 PM, Ye Bin wrote:
>> From: Ye Bin <yebin10@huawei.com>
>>
>> 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
>>
>
> I suppose we need to explain why we have this particular use case.
>
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.
>
> What about checking sb_rdonly(sb) before setting the journal feature, and
> skipping the setting if the filesystem is mounted as read-only?

Yes, I've thought about doing that too, but that would require us to set 
the journal's features again when remounting as rw.

>
> Regards,
> Yi.
>
>>
>> Fixes: 4fd5ea43bc11 ("jbd2: checksum journal superblock")
>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>> ---
>>   fs/jbd2/journal.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
>> index d480b94117cd..5b6e8c1a5e6a 100644
>> --- a/fs/jbd2/journal.c
>> +++ b/fs/jbd2/journal.c
>> @@ -2349,6 +2349,8 @@ 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);
>> +	if (jbd2_journal_has_csum_v2or3(journal))
>> +		sb->s_checksum = jbd2_superblock_csum(sb);
>>   	unlock_buffer(journal->j_sb_buffer);
>>   	jbd2_journal_init_transaction_limits(journal);
>>
>> @@ -2378,9 +2380,13 @@ 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);
>> +	if (jbd2_journal_has_csum_v2or3(journal))
>> +		sb->s_checksum = jbd2_superblock_csum(sb);
>> +	unlock_buffer(journal->j_sb_buffer);
>>   	jbd2_journal_init_transaction_limits(journal);
>>   }
>>   EXPORT_SYMBOL(jbd2_journal_clear_features);
>


  reply	other threads:[~2025-10-29 11:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28  6:47 [PATCH] jbd2: fix the inconsistency between checksum and data in memory for journal sb Ye Bin
2025-10-29  8:45 ` Zhang Yi
2025-10-29 11:44   ` yebin [this message]
2025-10-29 14:55 ` Darrick J. Wong
2025-10-30  2:13   ` Zhang Yi
2025-10-30 10:46 ` Jan Kara
2025-10-31  1:47   ` yebin

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=6901FE36.6030404@huaweicloud.com \
    --to=yebin@huaweicloud.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huaweicloud.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.