On 2023/8/3 22:38, Jan Kara wrote:
> On Tue 04-07-23 21:42:28, Zhang Yi wrote:
>> From: Zhang Yi <yi.zhang@xxxxxxxxxx>
>>
>> If JBD2_FEATURE_INCOMPAT_FAST_COMMIT bit is set, it means the journal
>> have fast commit records need to recover, so the fast commit size
>> should not be zero, and also the leftover normal journal size should
>> never less than JBD2_MIN_JOURNAL_BLOCKS. Add a check into the
>> journal_check_superblock() and drop the pointless branch when
>> initializing in-memory fastcommit parameters.
>>
>> Signed-off-by: Zhang Yi <yi.zhang@xxxxxxxxxx>
>
> Some comments below.
>
>
>> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
>> index efdb8db3c06e..210b532a3673 100644
>> --- a/fs/jbd2/journal.c
>> +++ b/fs/jbd2/journal.c
>> @@ -1392,6 +1392,18 @@ static int journal_check_superblock(journal_t *journal)
>> return err;
>> }
>>
>> + if (jbd2_has_feature_fast_commit(journal)) {
>> + int num_fc_blks = be32_to_cpu(sb->s_num_fc_blks);
>> +
>> + if (!num_fc_blks ||
>> + (be32_to_cpu(sb->s_maxlen) - num_fc_blks <
>> + JBD2_MIN_JOURNAL_BLOCKS)) {
>> + printk(KERN_ERR "JBD2: Invalid fast commit size %d\n",
>> + num_fc_blks);
>> + return err;
>> + }
>
> This is wrong sb->s_num_fc_blks == 0 means that the fast-commit area should
> have the default size of 256 blocks. At least that's how it behaves
> currently and we should not change the behavior.
Thanks for the review and correcting me. I missed the fc_debug_force
mount option, this option enable fast commit feature without init
sb->s_num_fc_blks to disk, so it could left over an unclean image with
fast_commit feature but sb->s_num_fc_blks is still zero. And the mke2fs
could also set sb->s_num_fc_blks to 0.
>
> Similarly if the number of fastcommit blocks was too big (i.e. there was
> not enough space left for ordinary journal), we effectively silently
> disable fastcommit and you break this behavior in this patch.
>
If the fastcommit is too big, jbd2_journal_initialize_fast_commit()
will detect this corruption and refuse to mount.
[ 1213.810719] JBD2: Cannot enable fast commits.
[ 1213.812282] EXT4-fs (pmem1): Failed to set fast commit journal feature
It only silently disable fastcommit while recovering the journal, but it
doesn't seem to make much sense, because the journal->j_last is likely to
be wrong (not point to the correct end of normal journal range) and will
probably lead to incorrect recovery. It seems better to report the error
and exit as early as possible. So I suppose we could keep this "too big"
check in journal_check_superblock(). How does that sound ?
Thanks,
Yi.
>
>> + }
>> +
>> if (jbd2_has_feature_csum2(journal) &&
>> jbd2_has_feature_csum3(journal)) {
>> /* Can't have checksum v2 and v3 at the same time! */
>> @@ -1460,7 +1472,6 @@ static int journal_load_superblock(journal_t *journal)
>> int err;
>> struct buffer_head *bh;
>> journal_superblock_t *sb;
>> - int num_fc_blocks;
>>
>> bh = getblk_unmovable(journal->j_dev, journal->j_blk_offset,
>> journal->j_blocksize);
>> @@ -1498,9 +1509,8 @@ static int journal_load_superblock(journal_t *journal)
>>
>> if (jbd2_has_feature_fast_commit(journal)) {
>> journal->j_fc_last = be32_to_cpu(sb->s_maxlen);
>> - num_fc_blocks = jbd2_journal_get_num_fc_blks(sb);
>> - if (journal->j_last - num_fc_blocks >= JBD2_MIN_JOURNAL_BLOCKS)
>> - journal->j_last = journal->j_fc_last - num_fc_blocks;
>> + journal->j_last = journal->j_fc_last -
>> + be32_to_cpu(sb->s_num_fc_blks);
>> journal->j_fc_first = journal->j_last + 1;
>> journal->j_fc_off = 0;
>> }
>> --
>> 2.39.2
>>
