New issue
Advanced search Search tips

Issue 766347 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 761911
issue 760007



Sign in to add a comment

ext4: reproduce inode corruption when FS not unmounted properly

Project Member Reported by gwendal@chromium.org, Sep 18 2017

Issue description

While investigating 760007, we found that we were not unmounting FS properly. With ext4 crypto, sometimge the corruptions were not recoverable by the kernel recovery code.

Reproduce the issue with a script:
- Create a 512MB loopback filesystem, 
- mount and create 10 encrypted directly,
- write 100 files in each.
- While sync, copy to a snapshot.
- unmount orginal filesystem, use the snapshot.
- check for inode and critical errors in dmesg when mounting snapshot.

After 1h, the kernel was not able to recovery the filesystem nicely:
[ 1895.344396] EXT4-fs error (device loop7): ext4_xattr_block_get:321: inode #1535: comm md5sum: bad block 5879
[ 1895.344493] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1535
[ 1895.344519] EXT4-fs error (device loop7): ext4_xattr_block_get:321: inode #1535: comm md5sum: bad block 5879
[ 1895.348835] EXT4-fs error (device loop7): ext4_xattr_delete_inode:1528: inode #1535: comm rm: bad block 5879
[ 1895.374041] EXT4-fs error (device loop7): ext4_xattr_block_get:321: inode #1536: comm md5sum: bad block 5880
[ 1895.374112] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1536
[ 1895.374140] EXT4-fs error (device loop7): ext4_xattr_block_get:321: inode #1536: comm md5sum: bad block 5880
[ 1895.378273] EXT4-fs error (device loop7): ext4_xattr_delete_inode:1528: inode #1536: comm rm: bad block 5880
[ 1895.403992] EXT4-fs error (device loop7): ext4_xattr_block_get:321: inode #1537: comm md5sum: bad block 5881
[ 1895.404096] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1537
[ 1895.404129] EXT4-fs error (device loop7): ext4_xattr_block_get:321: inode #1537: comm md5sum: bad block 5881
[ 1895.409156] EXT4-fs error (device loop7): ext4_xattr_delete_inode:1528: inode #1537: comm rm: bad block 5881
[ 1895.433454] EXT4-fs error (device loop7): ext4_xattr_block_get:321: inode #1538: comm md5sum: bad block 5882
[ 1895.433547] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1538
[ 1895.461815] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1539
[ 1895.490053] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1540
[ 1895.519322] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1541
[ 1895.547298] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1542
[ 1895.577937] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1543
[ 1895.607036] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1544
[ 1895.635690] SELinux: inode_doinit_with_dentry:  getxattr returned 5 for dev=loop7 ino=1545
[ 1895.649618] EXT4-fs (loop8): ext4_check_descriptors: Checksum for group 0 failed (34647!=39033)
[ 1895.649640] EXT4-fs (loop8): group descriptors corrupted!


I am using a somewhat older 3.18 to match R60 (commit 84ba9c911db9)
 
test_no_umount.sh
1.6 KB View Download
Blocking: 761911
I notice on my Caroline that the encrypted stateful partition doesn't have encrypt feature set on it's encrypted stateful filesystem -- though it is still present on the larger stateful filesystem.  But it doesn't directly affect encrypted stateful.

Comment 3 by uekawa@chromium.org, Sep 19 2017

encstateful is encrypted through dm-crypto so encstateful's file system itself doesn't have encrypt feature.

Sign in to add a comment