Created attachment 277273 [details] Reproducer Operating non-crafted Ext4 image with inline_inodes option enabled causes "checksum invalid" error How to reproduce: 1) dd if=/dev/zero of=ext4 bs=1M count=8 mkfs.ext4 ext4 -O inline_data -I 1024 # mke2fs 1.44.1 (24-Mar-2018) 2) Compile either v4.18-rc3 or tytso/dev (9a4bd84) with the attached config 3) Compile ext4-bug.c (see attachment for full source) char buf[64]; int main() { int fd = creat("./xyz", 0x30); truncate("./xyz", 1133); for (int i = 0; i < sizeof(buf); ++i) buf[i] = i + 1; write(fd, buf, 48); return 0; } 4) mount /dev/sda /mnt -t ext4 cd /mnt ../ext4-bug cd / umount /mnt mount /dev/sda /mnt -t ext4 #mount /mnt -o remount # Remounting gives different error message rmdir /mnt/xyz What happens: [ 4.848416] EXT4-fs error (device sda): ext4_iget:4812: inode #12: comm init: checksum invalid rmdir: '/mnt/xyz': Bad message
Created attachment 277275 [details] Kernel config
Thanks for the bug report. I've reproduced the problem, and will be looking at it.
Created attachment 277315 [details] Patch to fix the issue This should address the issue; thanks for reporting the bug!
Thank you! This seems to fix the original test case, but for some strange reasons replacing umount-mount pair of commands in the step 4) with just mount /mnt -o remount causes different error message [ 4.768872] EXT4-fs error (device sda): ext4_has_uninit_itable:3149: comm exe: Inode table for bg 0 marked as needing zeroing [ 4.770731] EXT4-fs (sda): re-mounted. Opts: (null) to be printed *at the remount time*. (Now rmdir is not necessary). PS: Hope I have not messed up code versions when retesting. :)
Hmm, I can't reproduce it: root@kvm-xfstests:/# mke2fs -t ext4 -O inline_data -I 1024 ext4.img 8M mke2fs 1.44.3 (10-July-2018) Creating regular file ext4.img Creating filesystem with 8192 1k blocks and 2048 inodes Allocating group tables: done Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done root@kvm-xfstests:/# mount ext4.img /mnt [ 312.864146] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null) root@kvm-xfstests:/# (cd /mnt ; /vdb/ext4-bug) root@kvm-xfstests:/# mount -o remount /mnt [ 320.985477] EXT4-fs (loop0): re-mounted. Opts: (null) root@kvm-xfstests:/# umount /mnt root@kvm-xfstests:/# e2fsck -nf ext4.img e2fsck 1.44.3 (10-July-2018) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information ext4.img: 12/2048 files (8.3% non-contiguous), 3153/8192 blocks root@kvm-xfstests:/# uname -a Linux kvm-xfstests 4.18.0-rc4-xfstests-00003-g362eca70b533 #422 SMP Tue Jul 10 01:08:22 EDT 2018 x86_64 GNU/Linux
Please excuse me for long delay. Hmm... Still seems to be reproducible on tytso/dev (commit 362eca70). As far as I understand, it includes this fix. Steps to reproduce: 1) Compile commit 362eca70 with the attached config for x86_64 arch 2) Run mkinitrd.sh attached -- it will create self-contained initrd 3) Unpack ext4.img (it is expected to be non-crafted, freshly created ext4 image, but I attach the precise image I tested with in case it depends on mkfs version) 4) Run qemu-system-x86_64 -kernel path/to/linux.git/arch/x86/boot/bzImage -initrd ./initrd.cpio -m 512M -drive file=ext4.img,index=0,format=raw What happens: Remounting... [ 4.812614] EXT4-fs error (device sda): ext4_has_uninit_itable:3149: comm exe: Inode table for bg 0 marked as needing zeroing [ 4.814356] EXT4-fs (sda): re-mounted. Opts: (null)
Created attachment 277455 [details] Self-contained initrd generator
Created attachment 277457 [details] Non-crafted ext4 image in case reproducibility depends on e2fsprogs version