linux-ext4 - Re: ext4 issue on linux-next(next-20251030)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <xrytdoegosn2qbvqdx6idvardvsbhj4blxnuschvgnl4i2bhxj@ezuawpusl6sn>
Date: Mon, 3 Nov 2025 09:46:34 +0100
From: Jan Kara <jack@...e.cz>
To: Bough Chen <haibo.chen@....com>
Cc: Theodore Tso <tytso@....edu>, "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)

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@...e.com>
SUSE Labs, CR