Re: mkfs.ext4 failed when orphan_file is enabled

[Kemeng Shi <shikemeng@huaweicloud.com>]

on 6/27/2023 10:46 AM, Kemeng Shi wrote:
> 
> 
> on 6/27/2023 2:00 AM, Theodore Ts'o wrote:
>> On Mon, Jun 26, 2023 at 08:48:23PM +0800, Kemeng Shi wrote:
>>> Hi all, I find that "kvm-xfstests -c ext4/1k ext4/049" is failed on
>>> current dev branch because of mkfs.ext4 failure.
>>
>> Hmm, I'm not seeing this mkfs.ext4 failure using 1.47.0.  I have two
>> cherry-picks on top of 1.47, but neither relate to mkfs.ext4:
>>
>>   24a11cc371a4 ("e2fsck: Suppress "orphan file is clean" message in preen mode")
>>
>> and
>>
>>   8798bbb81687 ("e2fsck: fix handling of a invalid symlink in an inline_data directory")
>>
>> See:
>>
>> root@kvm-xfstests:~# /sbin/mkfs.ext4  -F  -b 4096 -g 8192 -N 1024 -I 4096 /dev/vdc
>> mke2fs 1.47.0 (5-Feb-2023)
>> /dev/vdc contains a ext4 file system
>>         last mounted on /vdc on Sun Jun 25 22:14:30 2023
>> Discarding device blocks: done                            
>> Creating filesystem with 1310720 4k blocks and 1280 inodes
>> Filesystem UUID: 127d490e-6caa-45cf-b5da-5616c5564a1a
>> Superblock backups stored on blocks: 
>>         8192, 24576, 40960, 57344, 73728, 204800, 221184, 401408, 663552, 
>>         1024000
>>
>> Allocating group tables: done                            
>> Writing inode tables: done                            
>> Creating journal (16384 blocks): done
>> Writing superblocks and filesystem accounting information: done   
>>
>> Can you confirm what version of e2fsprogs you are using?  Is it
>> exactly 1.47.0, or do you have some additional commits (either from
>> the upstream master or maint branches) applied?
> For virutal machine, I use built-in e2fsprogs in image[1]. For host mahcine, I build mke2fs
> from the upstream master branch with commit e76886f76dfca ("Merge branch 'maint' into next").
> I find some more clues that rename from mke2fs to mkfs.ext4 will cause this issue:
> 
> /* make sure mkfs.ext4 and mke2fs is renamed */
> root@kvm-xfstests:~# md5sum /sbin/mkfs.ext4
> 746f94dbfef93ed68bd760530613b176  /sbin/mkfs.ext4
> root@kvm-xfstests:~# md5sum /sbin/mke2fs
> 746f94dbfef93ed68bd760530613b176  /sbin/mke2fs
> 
> /* /sbin/mkfs.ext4 failed */
> root@kvm-xfstests:~# /sbin/mkfs.ext4 -F  -b 4096 -g 8192 -N 1024 -I 4096 /dev/vdc
> mke2fs 1.47.0 (5-Feb-2023)
> /dev/vdc contains a ext2 file system
>         created on Tue Jun 27 10:28:17 2023
> Discarding device blocks: done
> Creating filesystem with 1310720 4k blocks and 1280 inodes
> Filesystem UUID: d7287d23-c4fa-42da-8d53-14078dec8d70
> Superblock backups stored on blocks:
>         8192, 24576, 40960, 57344, 73728, 204800, 221184, 401408, 663552,
>         1024000
> 
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (16384 blocks): done
> * mkfs.ext4: Inode checksum does not match inode while creating orphan file *
> 
> /* /sbin/mke2fs successed */
> root@kvm-xfstests:~# /sbin/mke2fs -F  -b 4096 -g 8192 -N 1024 -I 4096 /dev/vdc
> mke2fs 1.47.0 (5-Feb-2023)
> Discarding device blocks: done
> Creating filesystem with 1310720 4k blocks and 1280 inodes
> Filesystem UUID: 0e01e99b-52bf-4c2c-b986-fb497780bf40
> Superblock backups stored on blocks:
>         8192, 24576, 40960, 57344, 73728, 204800, 221184, 401408, 663552,
>         1024000
> 
> Allocating group tables: done
> Writing inode tables: done
> Writing superblocks and filesystem accounting information: done
> 
> This can be reproduced in my host machine too.
> 
> [1]https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/root_fs.img.amd64
> 
There are some updates for the issue. After a quick look at mke2fs.c,
I think the bug is triggered as following:
main
  ...

  /* unused inode is not zeroed dute as lazy_itable_init is set */
  write_inode_tables(fs, lazy_itable_init, itable_zeroed) (lazy_flag=1,
  itable_zeroed=0)

  ...

  ext2fs_create_orphan_file
    /* get a new uninitialized inode */
    ext2fs_new_inode
    /* read and check checksum of uninitialized inode */
    ext2fs_read_inode
      /* read uninitialized inode from disk */
      io_channel_read_blk64
      /* check checksum of non zeroed inode and failed here*/
      ext2fs_inode_csum_verify

I disable lazy_itable_init by force lazy_flag=0 when calling
write_inode_tables to prove this and the problem is solved
as expected.

Wish this help and correct me if I missed anything.

-- 
Best wishes
Kemeng Shi