linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	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 17:52:57 -0400	[thread overview]
Message-ID: <20250412215257.GF13132@mit.edu> (raw)
In-Reply-To: <CAGudoHGxr5gYb0JqPqF_J0MoSAb_qqoF4gaJMEdOhp51yobbLw@mail.gmail.com>

On Sat, Apr 12, 2025 at 06:26:09PM +0200, Mateusz Guzik wrote:
> > I tried to do the same thing for ext4, and failed miserably, but
> > that's probably because my logic for "maybe_acls" was broken since I'm
> > not familiar enough with ext4 at that level, and I made it do just

Linus, what problems did you run into?

> >         /* Initialize the "no ACL's" state for the simple cases */
> >         if (!ext4_test_inode_state(inode, EXT4_STATE_XATTR) && !ei->i_file_acl)
> >                 cache_no_acl(inode);
> >
> > which doesn't seem to be a strong enough text.

Linus, were you running into false positives or false negatives?  You
said "failed miserably", which seems to imply that you ran into cases
where cache_no_acl() got called when the inode actually had an ACL ---
e.g., a false positive.

That's different from what Mateuz is reporting which is that most
inodes w/o ACL were getting cache_no_acl(), but some cases
cache_no_acl() was't getting called when it should.  That is, a flase
negative:

> bpftrace over a kernel build shows almost everything is sorted out:
>  bpftrace -e 'kprobe:security_inode_permission { @[((struct inode
> *)arg0)->i_acl] = count(); }'
> 
> @[0xffffffffffffffff]: 23810
> @[0x0]: 65984202
> 
> That's just shy of 66 mln calls where the acls were explicitly set to
> empty, compared to less than 24k where it was the default "uncached"
> state.
> 
> So indeed *something* is missed, but the patch does cover almost everything.

So the test which we're talking about:

> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 4008551bbb2d..34189d85e363 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5071,7 +5071,12 @@ struct inode *__ext4_iget(struct super_block
> *sb, unsigned long ino,
>                 goto bad_inode;
>         }
> 
> +       /* Initialize the "no ACL's" state for the simple cases */
> +       if (!ext4_test_inode_state(inode, EXT4_STATE_XATTR) && !ei->i_file_acl)
> +               cache_no_acl(inode);
> +
>         brelse(iloc.bh);
> 

tests if the inode does not have an extended attribute.  Posix ACL's
are stored as xattr's --- but if there are any extended attributes (or
in some cases, inline data), in order to authoratatively determine
whether there is an ACL or not will require iterating over all of the
extended attributes.  This can be rather heavyweight, so doing it
unconditionally any time we do an iget() is probably not warranted.

Still, if this works 99.99% of the time, given that most peple don't
enable inline_data, and most folks aren't setting extended attributes,
it should be fine.  Of course, given that SELinux's security ID's are
stored as extended attriutes, at that point this optimization won't
work.  But if you are using SELinux, you probably don't care about
performance anyway.  :-)

					- Ted

  parent reply	other threads:[~2025-04-12 21:53 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                 ` Theodore Ts'o [this message]
2025-04-12 22:36                   ` generic_permission() optimization Linus Torvalds
2025-04-12 23:12                     ` Linus Torvalds
2025-04-12 23:55                     ` Theodore Ts'o
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=20250412215257.GF13132@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).