Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.14.0, Lustre 2.16.1
-
3
-
9223372036854775807
Description
If a fast symlink is also having an external xattr inode (eg. due to having a large number of hard links and growing trusted.link above 3072 bytes), then it is possible to trigger an invalid check in ldiskfs_is_fast_symlink() that thinks the inode is corrupted.
I confirmed that this bug also exists on vanilla ext4 in the rocky8.10 kernel (and by all appearances in the latest upstream ext4) when the ea_inode feature is enabled to create large external xattr inodes:
# touch /mnt/tmp/foo # ln -s foo /mnt/tmp/bar # setfattr -h -n trusted.test -v "$(dd if=/etc/services bs=4k count=1)" /mnt/tmp/bar # debugfs -c -R "stat bar" /dev/vg_test/lvtest debugfs 1.47.1-wc1 (18-May-2024) Inode: 24578 Type: symlink Mode: 0777 Flags: 0x0 Generation: 2897945315 Version: 0x00000000:00000004 User: 0 Group: 0 Project: 0 Size: 3 File ACL: 0 Links: 1 Blockcount: 8 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x6856970f:76cbbb28 -- Sat Jun 21 05:27:11 2025 atime: 0x685696ee:e15e1280 -- Sat Jun 21 05:26:38 2025 mtime: 0x6856945c:d93b5244 -- Sat Jun 21 05:15:40 2025 crtime: 0x6856945c:d93b5244 -- Sat Jun 21 05:15:40 2025 Size of extra inode fields: 32 Extended attributes: security.selinux (37) = "unconfined_u:object_r:unlabeled_t:s0\000" inode <24579> trusted.test (4096) # umount /mnt/tmp # mount -t ext4 /dev/vg_test/lvtest /mnt/tmp # ls -l /mnt/tmp ls: cannot access '/mnt/tmp/bar': Structure needs cleaning total 16 ? l?????????? ? ? ? ? ? bar 0 -rw-r--r--. 1 root root 0 Jun 21 05:14 foo 16 drwx------. 2 root root 16384 May 26 03:38 lost+found/ # dmesg | tail -1 EXT4-fs error (device dm-8): __ext4_iget:5098: inode #24578: block 7303014: comm ls: invalid block