* ext4 issue on linux-next(next-20251030) [not found] ` <20251023-qm_dts-v1-2-9830d6a45939@nxp.com> @ 2025-10-30 11:11 ` Bough Chen 2025-10-31 1:33 ` Theodore Tso 0 siblings, 1 reply; 5+ messages in thread From: Bough Chen @ 2025-10-30 11:11 UTC (permalink / raw) To: jack@suse.cz Cc: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, imx@lists.linux.dev Hi Jack, On the latest linux-next, I find your patch acf943e9768e ("ext4: fix checks for orphan inodes") trigger the following issue on our imx7d-sdb board. I do not have enough background knowledge of ext4, so don't know why there are orphan inodes on the partition with ext4. Not sure whether this is a real issue or we need some special operation on current ext4 partition. Do you have any suggestions to debug this issue? root@imx6ul7d:~# e2fsck -f /dev/mmcblk2p2 e2fsck 1.47.3 (8-Jul-2025) 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 root: 64959/570080 files (0.1% non-contiguous), 719492/1139298 blocks root@imx6ul7d:~# mount /dev/mmcblk2p2 test/ [ 203.776094] EXT4-fs (mmcblk2p2): mounted filesystem dc06048e-939b-4827-97ef-f815486f505f r/w with ordered data mode. Quota mode: none. root@imx6ul7d:~# umount /dev/mmcblk2p2 [ 210.088283] EXT4-fs (mmcblk2p2): unmounting filesystem dc06048e-939b-4827-97ef-f815486f505f. [ 210.104550] EXT4-fs (mmcblk2p2): Inode 1 (3148c11d): inode tracked as orphan! [ 210.104605] 3148c11d: efb7ffde 5f7b7fff e7fffbfe 677b6f7f ......{_.....o{g [ 210.104618] 961d5d65: feedff7e 7bfdefff 7fffffff fff3bebf ~......{........ [ 210.104630] 440e00b4: 9f77fdff cfd7ff7b 57b3ffe7 cfdfd777 ..w.{......Ww... [ 210.104641] d896c4c3: edecffaf ecfae6f3 e3cf7f5f f7fee7e5 ........_....... [ 210.104652] 594b2fff: 7bfbff9d f5bfab4f efffffff fef7ffff ...{O........... [ 210.104663] 48812578: f6bffadf 00000000 00000000 00000000 ................ root@imx6ul7d:~# [ 210.104674] 6940b116: 00000000 00000000 c697af68 c697af68 ........h...h... [ 210.104685] 5f2b32c1: c697af70 c697af70 c697af78 c697af78 p...p...x...x... [ 210.104696] 01fb95bd: c697af80 c697af80 00000000 00000000 ................ [ 210.104708] ae1bfce8: 00000000 00000000 c697af98 c697af98 ................ [ 210.104719] 659d4cf2: 00000000 cd7cffff 00000000 00000000 ......|......... [ 210.104729] 91d0ddfa: 00000000 00000000 00000000 00000000 ................ [ 210.104740] 0747a55c: c697afc0 c697afc0 00280000 00000000 ..........(..... [ 210.104751] 77b8b5de: 00000000 00000000 ffffffff ffffffff ................ [ 210.104762] 326357f2: c1017dc0 c565d400 c697b0b8 00000001 .}....e......... [ 210.104773] 3398af02: 00000001 00000000 00000000 00000000 ................ [ 210.104784] abe2702f: 00000000 00000000 00000000 00000000 ................ [ 210.104794] a7d16dda: 00000000 00000000 00000000 00000000 ................ [ 210.104805] f714e489: 00000000 00000000 00030003 000c0000 ................ [ 210.104816] 9969c6ba: 00000000 00000000 00000000 00000300 ................ [ 210.104827] 7b03ec5b: 00000000 00000000 00000000 00000000 ................ [ 210.104838] 8f2c1269: c697b050 c697b050 00000000 00000000 P...P........... [ 210.104849] d7cc3d73: 00000000 00000000 c697b068 c697b068 ........h...h... [ 210.104860] 90750112: c697b070 c697b070 c697b078 c697b078 p...p...x...x... [ 210.104696] 01fb95bd: c697af80 c697af80 00000000 00000000 ................ [16/1961] [ 210.104708] ae1bfce8: 00000000 00000000 c697af98 c697af98 ................ [ 210.104719] 659d4cf2: 00000000 cd7cffff 00000000 00000000 ......|......... [ 210.104729] 91d0ddfa: 00000000 00000000 00000000 00000000 ................ [ 210.104740] 0747a55c: c697afc0 c697afc0 00280000 00000000 ..........(..... [ 210.104751] 77b8b5de: 00000000 00000000 ffffffff ffffffff ................ [ 210.104762] 326357f2: c1017dc0 c565d400 c697b0b8 00000001 .}....e......... [ 210.104773] 3398af02: 00000001 00000000 00000000 00000000 ................ [ 210.104784] abe2702f: 00000000 00000000 00000000 00000000 ................ [ 210.104794] a7d16dda: 00000000 00000000 00000000 00000000 ................ [ 210.104805] f714e489: 00000000 00000000 00030003 000c0000 ................ [ 210.104816] 9969c6ba: 00000000 00000000 00000000 00000300 ................ [ 210.104827] 7b03ec5b: 00000000 00000000 00000000 00000000 ................ [ 210.104838] 8f2c1269: c697b050 c697b050 00000000 00000000 P...P........... [ 210.104849] d7cc3d73: 00000000 00000000 c697b068 c697b068 ........h...h... [ 210.104860] 90750112: c697b070 c697b070 c697b078 c697b078 p...p...x...x... [ 210.104871] 3d683c4a: c697b080 c697b080 00000000 00000000 ................ [ 210.104881] 6cb03d5d: 00000002 00000000 00000000 00000000 ................ [ 210.104892] 7c8038eb: 00000000 00000000 00000000 00000000 ................ [ 210.104903] 093a7b94: c1017e40 00000000 c697afc8 001f001f @~.............. [ 210.104914] 9fe63af0: 00000021 00000000 00000000 00000000 !............... [ 210.104925] 1889fb16: 00000000 00000000 c697b0d8 c697b0d8 ................ [ 210.104936] 59cb62ef: 00100cca 00000000 00000000 00000000 ................ [ 210.104947] 86fb5791: 00000000 00000000 c1017ec8 00000010 .........~...... [ 210.104958] b399200b: 00000000 00000000 c697b108 c697b108 ................ [ 210.104968] 7ecef62e: 00000000 00000000 00000000 00000000 ................ [ 210.104979] e35002c8: c697b120 c697b120 00000000 c697b12c ... .......,... [ 210.104990] 3c940dbc: c697b12c 00000000 00000000 00000000 ,............... [ 210.105001] f8c050d9: 00000000 00000000 00000000 fffffff7 ................ [ 210.105012] c8073821: ffffff5f ffffdfd1 ffeffffc ffff6556 _...........Ve.. [ 210.105023] 84651cd7: 00000000 00000000 00000000 00000000 ................ [ 210.105033] f8a81094: 00000000 00000000 00000000 c697b17c ............|... [ 210.105044] aaea6bf1: c697b17c 00000000 00000000 00000000 |............... [ 210.105055] 758d8f80: ffff5efa 00000000 ffefcf6e ffffffef .^......n....... [ 210.105066] 171a7e4a: 00000000 00000000 00000000 00000000 ................ [ 210.105077] 5da2c755: c697b1b0 c697b1b0 ffe00000 c697b1bc ................ [ 210.105088] 3b69580b: c697b1bc c03ffb38 00000000 00000000 ....8.?......... [ 210.105099] 43f12395: 00000000 00000000 00000000 ffeff3f7 ................ [ 210.105108] f17da383: ffffd7fe ffefeffa ........ [ 210.105121] CPU: 0 UID: 0 PID: 777 Comm: umount Not tainted 6.18.0-rc3-next-20251030-00003-g01f4df1f83c5 #12 VOLUNTARY [ 210.105137] Hardware name: Freescale i.MX7 Dual (Device Tree) [ 210.105145] Call trace: [ 210.105162] unwind_backtrace from show_stack+0x10/0x14 [ 210.105203] show_stack from dump_stack_lvl+0x54/0x68 [ 210.105224] dump_stack_lvl from ext4_destroy_inode+0x70/0x10c [ 210.105248] ext4_destroy_inode from destroy_inode+0x3c/0x64 [ 210.105272] destroy_inode from ext4_mb_release+0x278/0x3ec [ 210.105297] ext4_mb_release from ext4_put_super+0xec/0x42c [ 210.105320] ext4_put_super from generic_shutdown_super+0x70/0x178 [ 210.105343] generic_shutdown_super from kill_block_super+0x10/0x2c [ 210.105361] kill_block_super from ext4_kill_sb+0x18/0x30 [ 210.105379] ext4_kill_sb from deactivate_locked_super+0x50/0x98 [ 210.105397] deactivate_locked_super from cleanup_mnt+0xd8/0x178 [ 210.105415] cleanup_mnt from task_work_run+0x98/0x108 [ 210.105433] task_work_run from do_work_pending+0x4a0/0x4c4 [ 210.105453] do_work_pending from slow_work_pending+0xc/0x24 [ 210.105473] Exception stack(0xf0b89fb0 to 0xf0b89ff8) [ 210.105486] 9fa0: 00000000 00000000 0100b870 00000002 [ 210.105498] 9fc0: 0100b2e0 0100b870 b6ef88dc 00000034 00000000 0100b370 0100b550 0100b2e0 [ 210.105509] 9fe0: 00000034 bea799cc b6e48e4f b6db9836 60070030 0100b870 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ext4 issue on linux-next(next-20251030) 2025-10-30 11:11 ` ext4 issue on linux-next(next-20251030) Bough Chen @ 2025-10-31 1:33 ` Theodore Tso 2025-10-31 2:31 ` Bough Chen 0 siblings, 1 reply; 5+ messages in thread From: Theodore Tso @ 2025-10-31 1:33 UTC (permalink / raw) To: Bough Chen Cc: jack@suse.cz, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, imx@lists.linux.dev On Thu, Oct 30, 2025 at 11:11:51AM +0000, Bough Chen wrote: > Hi Jack, > > On the latest linux-next, I find your patch acf943e9768e ("ext4: fix checks for orphan inodes") trigger the following issue on our imx7d-sdb board. > I do not have enough background knowledge of ext4, so don't know why there are orphan inodes on the partition with ext4. Not sure whether this > is a real issue or we need some special operation on current ext4 partition. If you are willing to let me to see your file names, you could send me just the metadata blocks so I can examine file system image. The details are in the REPORTING BUGS section of the e2fsck man page and as well as the RAW IMAGE FILE and QCOW2 IMAGE FILE sections of the e2image man page, but the short version is: e2image -Q /dev/mmcblkp2p2 fs.qcow2 bzip2 -z fs.qcow2 ... and then send me the fs.qcow2.bz file. If you aren't please try running "dumpe2fs -h /dev/mmcblk2p2" and send me the output. Thanks, - Ted ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: ext4 issue on linux-next(next-20251030) 2025-10-31 1:33 ` Theodore Tso @ 2025-10-31 2:31 ` Bough Chen 2025-11-03 3:57 ` Bough Chen 0 siblings, 1 reply; 5+ messages in thread From: Bough Chen @ 2025-10-31 2:31 UTC (permalink / raw) To: Theodore Tso Cc: jack@suse.cz, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, imx@lists.linux.dev [-- Attachment #1: Type: text/plain, Size: 4223 bytes --] Hi Theodore, Thanks for your quick reply. root@imx6ul7d:~# e2image -Q /dev/mmcblk2p2 fs.qcow2 e2image 1.47.3 (8-Jul-2025) root@imx6ul7d:~# bzip2 -z fs.qcow2 for the fs.qcow2.bz, please refer to the attachement. For this /dev/mmcblk2p2, sometimes umount do not meet this issue, but after several mount/umount operation, this issue come up again. I also paste the log of your second suggestion: root@imx6ul7d:~# dumpe2fs -h /dev/mmcblk2p2 [16/1922] dumpe2fs 1.47.3 (8-Jul-2025) Filesystem volume name: root Last mounted on: <not available> Filesystem UUID: dc06048e-939b-4827-97ef-f815486f505f Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index orphan_file filetype extent 64bit flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nli nk extra_isize metadata_csum Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 570080 Block count: 1139298 Reserved block count: 56964 Overhead clusters: 56548 Free blocks: 419806 Free inodes: 505121 First block: 0 Block size: 4096 Fragment size: 4096 Group descriptor size: 64 Reserved GDT blocks: 556 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16288 Inode blocks per group: 1018 Flex block group size: 16 Filesystem created: Tue Apr 5 23:00:00 2011 Last mount time: Fri Oct 31 02:18:16 2025 Last write time: Fri Oct 31 02:18:17 2025 Mount count: 6 Maximum mount count: -1 Last checked: Thu Oct 30 10:35:48 2025 Check interval: 0 (<none>) Lifetime writes: 4248 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 32 Desired extra isize: 32 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: ff13b55b-8055-50d5-88d5-80782d2e8e86 Journal backup: inode blocks Checksum type: crc32c Checksum: 0xff831d21 Checksum seed: 0x794f2ccc Orphan file inode: 12 Journal features: (none) Total journal size: 64M Total journal blocks: 16384 Max transaction length: 16384 Fast commit length: 0 Journal sequence: 0x00000002 Journal start: 0 Regards Haibo Chen > -----Original Message----- > From: Theodore Tso <tytso@mit.edu> > Sent: 2025年10月31日 9:34 > To: Bough Chen <haibo.chen@nxp.com> > Cc: jack@suse.cz; adilger.kernel@dilger.ca; linux-ext4@vger.kernel.org; > imx@lists.linux.dev > Subject: Re: ext4 issue on linux-next(next-20251030) > > On Thu, Oct 30, 2025 at 11:11:51AM +0000, Bough Chen wrote: > > Hi Jack, > > > > On the latest linux-next, I find your patch acf943e9768e ("ext4: fix checks for > orphan inodes") trigger the following issue on our imx7d-sdb board. > > I do not have enough background knowledge of ext4, so don't know why > > there are orphan inodes on the partition with ext4. Not sure whether this is a > real issue or we need some special operation on current ext4 partition. > > If you are willing to let me to see your file names, you could send me just the > metadata blocks so I can examine file system image. The details are in the > REPORTING BUGS section of the e2fsck man page and as well as the RAW > IMAGE FILE and QCOW2 IMAGE FILE sections of the e2image man page, but the > short version is: > > > e2image -Q /dev/mmcblkp2p2 fs.qcow2 > bzip2 -z fs.qcow2 > > ... and then send me the fs.qcow2.bz file. > > If you aren't please try running "dumpe2fs -h /dev/mmcblk2p2" and send me > the output. > > Thanks, > > - Ted [-- Attachment #2: fs.qcow2.bz2 --] [-- Type: application/octet-stream, Size: 1265456 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: ext4 issue on linux-next(next-20251030) 2025-10-31 2:31 ` Bough Chen @ 2025-11-03 3:57 ` Bough Chen 2025-11-03 8:46 ` Jan Kara 0 siblings, 1 reply; 5+ messages in thread From: Bough Chen @ 2025-11-03 3:57 UTC (permalink / raw) To: Theodore Tso Cc: jack@suse.cz, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, imx@lists.linux.dev Hi All, I find something when debug, share the finding here: I notice every time this issue happen, the log always show inode 1, so I think this is supper inode related. And seems related to the i_state_flags of struct ext4_inode_info [ 210.104663] 48812578: f6bffadf 00000000 00000000 00000000 Here the i_state_flags = 0xf6bffadf, the Inode dynamic state flags only touch to bit0~bit12, so this i_state_flags is abnormal. When I add the following changes, this issue gone: diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 66f92f832b0fb..c6c2d32d5531b 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1396,6 +1396,7 @@ static struct inode *ext4_alloc_inode(struct super_block *sb) inode_set_iversion(&ei->vfs_inode, 1); ei->i_flags = 0; + ext4_clear_state_flags(ei); spin_lock_init(&ei->i_raw_lock); ei->i_prealloc_node = RB_ROOT; atomic_set(&ei->i_prealloc_active, 0); This can explain why this issue can't be reproduce 100%. And can also explain why only imx6/7 series meet this issue, but imx8/9 not, because imx6/7 is arm32 core, it use i_state_flags, but imx8/9 use arm64 core, do not use i_state_flags. This issue may exist long time, but Jack's patch trigger this issue. I also have the following concern: Why need to distinguish arch32 and arch64, why not use u64 to merge these two casees? diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 46f54d0a4bfe9..7369e165efc0f 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1034,10 +1034,7 @@ struct ext4_inode_info { */ ext4_group_t i_block_group; ext4_lblk_t i_dir_start_lookup; -#if (BITS_PER_LONG < 64) - unsigned long i_state_flags; /* Dynamic state flags */ -#endif - unsigned long i_flags; + u64 i_flags; /* * Extended attributes can be read independently of the main file @@ -1973,21 +1970,12 @@ EXT4_INODE_BIT_FNS(flag, flags, 0) static inline int ext4_test_inode_state(struct inode *inode, int bit); static inline void ext4_set_inode_state(struct inode *inode, int bit); static inline void ext4_clear_inode_state(struct inode *inode, int bit); -#if (BITS_PER_LONG < 64) -EXT4_INODE_BIT_FNS(state, state_flags, 0) - -static inline void ext4_clear_state_flags(struct ext4_inode_info *ei) -{ - (ei)->i_state_flags = 0; -} -#else EXT4_INODE_BIT_FNS(state, flags, 32) static inline void ext4_clear_state_flags(struct ext4_inode_info *ei) { /* We depend on the fact that callers will set i_flags */ } -#endif #else /* Assume that user mode programs are passing in an ext4fs superblock, not * a kernel struct super_block. This will allow us to call the feature-test Regards Haibo Chen > -----Original Message----- > From: Bough Chen > Sent: 2025年10月31日 10:31 > To: Theodore Tso <tytso@mit.edu> > Cc: jack@suse.cz; adilger.kernel@dilger.ca; > linux-ext4@vger.kernel.org; imx@lists.linux.dev > Subject: RE: ext4 issue on linux-next(next-20251030) > > Hi Theodore, > > Thanks for your quick reply. > > root@imx6ul7d:~# e2image -Q /dev/mmcblk2p2 fs.qcow2 e2image 1.47.3 > (8-Jul-2025) root@imx6ul7d:~# bzip2 -z fs.qcow2 > > for the fs.qcow2.bz, please refer to the attachement. > > For this /dev/mmcblk2p2, sometimes umount do not meet this issue, but > after several mount/umount operation, this issue come up again. > > I also paste the log of your second suggestion: > > root@imx6ul7d:~# dumpe2fs -h /dev/mmcblk2p2 [16/1922] dumpe2fs 1.47.3 > (8-Jul-2025) > Filesystem volume name: root > Last mounted on: <not available> > Filesystem UUID: dc06048e-939b-4827-97ef-f815486f505f > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index > orphan_file filetype extent 64bit flex_bg metadata_csum_seed > sparse_super large_file huge_file dir_nli nk extra_isize metadata_csum > Filesystem flags: signed_directory_hash > Default mount options: user_xattr acl > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 570080 > Block count: 1139298 > Reserved block count: 56964 > Overhead clusters: 56548 > Free blocks: 419806 > Free inodes: 505121 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Group descriptor size: 64 > Reserved GDT blocks: 556 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 16288 > Inode blocks per group: 1018 > Flex block group size: 16 > Filesystem created: Tue Apr 5 23:00:00 2011 > Last mount time: Fri Oct 31 02:18:16 2025 > Last write time: Fri Oct 31 02:18:17 2025 > Mount count: 6 > Maximum mount count: -1 > Last checked: Thu Oct 30 10:35:48 2025 > Check interval: 0 (<none>) > Lifetime writes: 4248 MB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 32 > Desired extra isize: 32 > Journal inode: 8 > Default directory hash: half_md4 > Directory Hash Seed: ff13b55b-8055-50d5-88d5-80782d2e8e86 > Journal backup: inode blocks > Checksum type: crc32c > Checksum: 0xff831d21 > Checksum seed: 0x794f2ccc > Orphan file inode: 12 > Journal features: (none) > Total journal size: 64M > Total journal blocks: 16384 > Max transaction length: 16384 > Fast commit length: 0 > Journal sequence: 0x00000002 > Journal start: 0 > > Regards > Haibo Chen > > > -----Original Message----- > > From: Theodore Tso <tytso@mit.edu> > > Sent: 2025年10月31日 9:34 > > To: Bough Chen <haibo.chen@nxp.com> > > Cc: jack@suse.cz; adilger.kernel@dilger.ca; > > linux-ext4@vger.kernel.org; imx@lists.linux.dev > > Subject: Re: ext4 issue on linux-next(next-20251030) > > > > On Thu, Oct 30, 2025 at 11:11:51AM +0000, Bough Chen wrote: > > > Hi Jack, > > > > > > On the latest linux-next, I find your patch acf943e9768e ("ext4: > > > fix checks for > > orphan inodes") trigger the following issue on our imx7d-sdb board. > > > I do not have enough background knowledge of ext4, so don't know > > > why there are orphan inodes on the partition with ext4. Not sure > > > whether this is a > > real issue or we need some special operation on current ext4 partition. > > > > If you are willing to let me to see your file names, you could send > > me just the metadata blocks so I can examine file system image. The > > details are in the REPORTING BUGS section of the e2fsck man page and > > as well as the RAW IMAGE FILE and QCOW2 IMAGE FILE sections of the > > e2image man page, but the short version is: > > > > > > e2image -Q /dev/mmcblkp2p2 fs.qcow2 > > bzip2 -z fs.qcow2 > > > > ... and then send me the fs.qcow2.bz file. > > > > If you aren't please try running "dumpe2fs -h /dev/mmcblk2p2" and > > send me the output. > > > > Thanks, > > > > - Ted ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: ext4 issue on linux-next(next-20251030) 2025-11-03 3:57 ` Bough Chen @ 2025-11-03 8:46 ` Jan Kara 0 siblings, 0 replies; 5+ messages in thread From: Jan Kara @ 2025-11-03 8:46 UTC (permalink / raw) To: Bough Chen Cc: Theodore Tso, jack@suse.cz, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, imx@lists.linux.dev On Mon 03-11-25 03:57:37, Bough Chen wrote: > Hi All, > > I find something when debug, share the finding here: > > I notice every time this issue happen, the log always show inode 1, so I > think this is supper inode related. And seems related to the > i_state_flags of struct ext4_inode_info > > [ 210.104663] 48812578: f6bffadf 00000000 00000000 00000000 > > Here the i_state_flags = 0xf6bffadf, the Inode dynamic state flags only > touch to bit0~bit12, so this i_state_flags is abnormal. > > When I add the following changes, this issue gone: > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > index 66f92f832b0fb..c6c2d32d5531b 100644 > --- a/fs/ext4/super.c > +++ b/fs/ext4/super.c > @@ -1396,6 +1396,7 @@ static struct inode *ext4_alloc_inode(struct super_block *sb) > > inode_set_iversion(&ei->vfs_inode, 1); > ei->i_flags = 0; > + ext4_clear_state_flags(ei); > spin_lock_init(&ei->i_raw_lock); > ei->i_prealloc_node = RB_ROOT; > atomic_set(&ei->i_prealloc_active, 0); OK, that's a good catch. I was scratching my head how inode with ino 1 could get orphan bit set when the kernel should never touch it. Now I've found out mbcache abuses EXT4_BAD_INO for its internal purposes so what we complain about is an in-memory auxiliary inode used by mbcache. Indeed it looks safer to initialize i_state_flags in ext4_alloc_inode() and we can drop the initialization from __ext4_iget() and __ext4_new_inode(). > This can explain why this issue can't be reproduce 100%. And can also > explain why only imx6/7 series meet this issue, but imx8/9 not, because > imx6/7 is arm32 core, it use i_state_flags, but imx8/9 use arm64 core, do > not use i_state_flags. > > This issue may exist long time, but Jack's patch trigger this issue. > > I also have the following concern: > Why need to distinguish arch32 and arch64, why not use u64 to merge these > two casees? Because atomic bit operations are only guaranteed to work on unsigned long type (32-bit on 32-bit architectures), not on u64 type. Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-11-03 8:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20251023-qm_dts-v1-0-9830d6a45939@nxp.com>
[not found] ` <20251023-qm_dts-v1-2-9830d6a45939@nxp.com>
2025-10-30 11:11 ` ext4 issue on linux-next(next-20251030) Bough Chen
2025-10-31 1:33 ` Theodore Tso
2025-10-31 2:31 ` Bough Chen
2025-11-03 3:57 ` Bough Chen
2025-11-03 8:46 ` Jan Kara
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox