| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID:
<AS1PR04MB950288682BF1CA58C32AE0F390C7A@AS1PR04MB9502.eurprd04.prod.outlook.com>
Date: Mon, 3 Nov 2025 03:57:37 +0000
From: Bough Chen <haibo.chen@....com>
To: Theodore Tso <tytso@....edu>
CC: "jack@...e.cz" <jack@...e.cz>, "adilger.kernel@...ger.ca"
<adilger.kernel@...ger.ca>, "linux-ext4@...r.kernel.org"
<linux-ext4@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: RE: ext4 issue on linux-next(next-20251030)
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@....edu>
> Cc: jack@...e.cz; adilger.kernel@...ger.ca;
> linux-ext4@...r.kernel.org; imx@...ts.linux.dev
> Subject: RE: ext4 issue on linux-next(next-20251030)
>
> Hi Theodore,
>
> Thanks for your quick reply.
>
> root@...6ul7d:~# e2image -Q /dev/mmcblk2p2 fs.qcow2 e2image 1.47.3
> (8-Jul-2025) root@...6ul7d:~# 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@...6ul7d:~# 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@....edu>
> > Sent: 2025年10月31日 9:34
> > To: Bough Chen <haibo.chen@....com>
> > Cc: jack@...e.cz; adilger.kernel@...ger.ca;
> > linux-ext4@...r.kernel.org; imx@...ts.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
Powered by blists - more mailing lists