linux-ext4 - Re: generic_permission() optimization

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGudoHFciRp7qJtaHSOhLAxpCfT1NEf0+MN0iprnOYORYgXKbw@mail.gmail.com>
Date: Wed, 5 Nov 2025 12:50:10 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Christian Brauner <brauner@...nel.org>, 
	Al Viro <viro@...iv.linux.org.uk>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, 
	Jan Kara <jack@...e.cz>, Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: generic_permission() optimization

On Sun, Apr 13, 2025 at 2:40 PM Theodore Ts'o <tytso@....edu> wrote:
>
> On Sun, Apr 13, 2025 at 11:41:47AM +0200, Mateusz Guzik wrote:
> > This is the rootfs of the thing, so I tried it out with merely
> > printing it. I got 70 entries at boot time. I don't think figuring out
> > what this is specifically is warranted (it is on debian though).
>
> Well, can you run:
>
> debugfs -R "stat <INO>" /dev/ROOT_DEV
>
> on say, two or three of the inodes (replace INO with a number, and
> ROOT_DEV with the root file system device) and send me the result?
> That would be really helpful in understanding what might be going on.
>
> > So... I think this is good enough to commit? I had no part in writing
> > the patch and I'm not an ext4 person, so I'm not submitting it myself.
> >
> > Ted, you seem fine with the patch, so perhaps you could do the needful(tm)?
>
> Sure, I'll put together a more formal patch and do full QA run and
> checking of the code paths, as a supposed a fairly superficial review
> and hack.
>

It looks like this well through the cracks.

To recount, here is the patch (by Linus, not me):
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index f386de8c12f6..3e0ba7c4723a 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5109,6 +5109,11 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>                 goto bad_inode;
>         brelse(iloc.bh);
>
> +       if (test_opt(sb, DEBUG) &&
> +           (ext4_test_inode_state(inode, EXT4_STATE_XATTR) ||
> +            ei->i_file_acl))
> +               ext4_msg(sb, KERN_DEBUG, "has xattr ino %lu", inode->i_ino);
> +
>         unlock_new_inode(inode);
>         return inode;

In my tests it covered most real-world lookups on my debian box.

Sorting this out acts as blocker for a lookup optimization I'm working
on which bypasses all perm checking if an inode has a flag indicating
everyone can traverse through it.