All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mateusz Guzik <mjguzik@gmail.com>,
	Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: generic_permission() optimization
Date: Sat, 12 Apr 2025 19:55:35 -0400	[thread overview]
Message-ID: <20250412235535.GH13132@mit.edu> (raw)
In-Reply-To: <CAHk-=wifig365Ej8JQrXBzK1_BzU9H9kqvvbBGuboF7CzR28VQ@mail.gmail.com>

On Sat, Apr 12, 2025 at 03:36:00PM -0700, Linus Torvalds wrote:
> Indeed. I sent a query to the ext4 list (and I think you) about
> whether my test was even the right one.

Sorry, I must have not seen that message; at least, I don't have any
memory of it.

> Also, while I did a "getfattr -dR" to see if there are any *existing*
> attributes (and couldn't find any), I also assume that if a file has
> ever *had* any attributes, the filesystem may have the attribute block
> allocated even if it's now empty.

Well, getfattr will only show user xattrs.  It won't show security.*
xattr's that might have been set by SELinux, or a
system.posix_acl_access xattr.

> I assume there's some trivial e2fstools thing to show things like
> that, but it needs more ext4 specific knowledge than I have.

Yes, we can test for this using the debugfs command.  For exaple:

root@kvm-xfstests:~# debugfs /dev/vdc
debugfs 1.47.2-rc1 (28-Nov-2024)
debugfs:  stat <13>
Inode: 13   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 1672288850    Version: 0x00000000:00000003
User:     0   Group:     0   Project:     0   Size: 286
File ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x67faf5d0:30d0b2e4 -- Sat Apr 12 19:22:56 2025
 atime: 0x67faf571:7064bd50 -- Sat Apr 12 19:21:21 2025
 mtime: 0x67faf571:71236aa8 -- Sat Apr 12 19:21:21 2025
crtime: 0x67faf571:7064bd50 -- Sat Apr 12 19:21:21 2025
Size of extra inode fields: 32
Extended attributes:
  system.posix_acl_access (28) = 01 00 00 00 01 00 06 00 02 00 04 00 b7 7a 00 00 04 00 04 00 10 00 04 00 20 00 04 00 
Inode checksum: 0xc8f7f1a7
EXTENTS:
(0):33792

(If you know the pathname instead of the inode number, you can also
give that to debugfs's stat command, e.g., "stat /lost+found")

I tested it with a simple variant of your patch, and seems to do the right
thing.  Mateusz, if you want, try the following patch, and then mount
your test file system with "mount -o debug".  (The test_opt is to
avoid a huge amount of noise on your root file system; you can skip it
if it's more trouble than it's worth.)  The patch has a reversed
seense of the test, so it will print a message for every one where
cache_no_acl *wouldn't* be called.  You casn then use debugfs's "stat
<ino#>" to verify whether it has some kind of extended attribute.

	   	  	     	      - Ted

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;
 

  parent reply	other threads:[~2025-04-12 23:55 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-31  4:16 generic_permission() optimization Linus Torvalds
2024-10-31  6:05 ` Al Viro
2024-10-31  6:42   ` Linus Torvalds
2024-10-31 18:14     ` Linus Torvalds
2024-10-31 22:28       ` Al Viro
2024-10-31 22:34         ` Linus Torvalds
2024-11-01  1:17           ` Linus Torvalds
2024-11-01  1:27             ` Al Viro
2024-11-01 13:15             ` Christian Brauner
2024-10-31 13:02 ` Christian Brauner
2024-10-31 19:04   ` Linus Torvalds
2024-10-31 22:02     ` Linus Torvalds
2024-10-31 22:31       ` Linus Torvalds
2024-11-07 19:54         ` Linus Torvalds
2024-11-07 22:22           ` Mateusz Guzik
2024-11-07 22:49             ` Linus Torvalds
2025-04-12 16:26               ` Mateusz Guzik
2025-04-12 20:22                 ` Linus Torvalds
2025-04-14 10:21                   ` Christian Brauner
2025-04-16 13:17                     ` [PATCH RFC 0/3] mnt_idmapping: avoid pointer chase & inline low-level helpers Christian Brauner
2025-04-16 13:17                       ` [PATCH RFC 1/3] inode: add fastpath for filesystem user namespace retrieval Christian Brauner
2025-04-16 13:49                         ` Mateusz Guzik
2025-04-16 14:14                           ` Christian Brauner
2025-04-22 10:37                         ` Jan Kara
2025-04-22 13:33                           ` Mateusz Guzik
2025-04-22 14:05                             ` Christian Brauner
2025-04-16 13:17                       ` [PATCH RFC 2/3] mnt_idmapping: add struct mnt_idmap to header Christian Brauner
2025-04-16 13:17                       ` [PATCH RFC 3/3] mnt_idmapping: inline all low-level helpers Christian Brauner
2025-04-16 15:04                         ` Linus Torvalds
2025-04-22  9:28                           ` Christian Brauner
2025-04-12 21:52                 ` generic_permission() optimization Theodore Ts'o
2025-04-12 22:36                   ` Linus Torvalds
2025-04-12 23:12                     ` Linus Torvalds
2025-04-12 23:55                     ` Theodore Ts'o [this message]
2025-04-13  9:41                       ` Mateusz Guzik
2025-04-13 12:40                         ` Theodore Ts'o
2025-04-13 12:52                           ` Mateusz Guzik
2025-04-13 17:29                             ` Theodore Ts'o
2025-11-05 11:50                           ` Mateusz Guzik
2025-11-05 11:51                             ` Mateusz Guzik
2025-11-05 13:37                               ` Jan Kara
2025-11-17 11:42                                 ` Mateusz Guzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250412235535.GH13132@mit.edu \
    --to=tytso@mit.edu \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.