The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Luis Henriques <luis@igalia.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	 fuse-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
	 Matt Harvey <mharvey@jumptrading.com>,
	kernel-dev@igalia.com,  Seth Forshee <sforshee@kernel.org>,
	 Christian Brauner <brauner@kernel.org>,
	 Jeff Layton <jlayton@kernel.org>
Subject: Re: [PATCH] fuse: cache POSIX ACLs when setting them
Date: Thu, 02 Jul 2026 09:56:09 +0100	[thread overview]
Message-ID: <87o6gp7ot2.fsf@wotan.olymp> (raw)
In-Reply-To: <CAOQ4uxg-LcCp5_2OGFo71ejJEPc14uL_D6n04jwy3C2GuoWy7g@mail.gmail.com> (Amir Goldstein's message of "Thu, 2 Jul 2026 00:58:40 +0200")

On Thu, Jul 02 2026, Amir Goldstein wrote:

> On Wed, Jul 1, 2026 at 2:24 PM Luis Henriques <luis@igalia.com> wrote:
>>
>> On Wed, Jul 01 2026, Amir Goldstein wrote:
>>
>> > On Wed, Jul 1, 2026 at 1:05 PM Luis Henriques <luis@igalia.com> wrote:
>> >>
>> >> When setting an ACL in an inode we can immediately add it to the cache.
>> >> This is a small optimisation, as currently an ACL is only added to the
>> >> cache when reading it again, which involves an extra GETXATTR hop into
>> >> user-space.
>> >>
>> >> Signed-off-by: Luis Henriques <luis@igalia.com>
>> >> ---
>> >>  fs/fuse/acl.c | 2 ++
>> >>  1 file changed, 2 insertions(+)
>> >>
>> >> diff --git a/fs/fuse/acl.c b/fs/fuse/acl.c
>> >> index 31fb50e16aed..c2584bb75ec7 100644
>> >> --- a/fs/fuse/acl.c
>> >> +++ b/fs/fuse/acl.c
>> >> @@ -155,6 +155,8 @@ int fuse_set_acl(struct mnt_idmap *idmap, struct dentry *dentry,
>> >>                  */
>> >>                 forget_all_cached_acls(inode);
>> >>                 fuse_invalidate_attr(inode);
>> >> +               if (!ret)
>> >> +                       set_cached_acl(inode, type, acl);
>> >
>> > This is undoing what forget_all_cached_acls() explicitly tries to do.
>> > I think the reason is that kernel code cannot assume the server did
>> > not modify ACL before storing them, not sure, but NFS does the same thing
>> > with nfs_zap_acl_cache().
>>
>> In my understanding, forget_all_cached_acls() is cleaning any previously
>> cached ACLs (even if the SETXATTR failed!).  So it made sense to me to
>> cache the new ACL just like other filesystems seem to be doing.
>
> Local filesystems do, remote filesystems not always.

True.  Even ceph, which is the remote filesystem I'm most familiar with,
caches ACLs when setting them only if the client has the right
capabilities for doing so.

>> On the other hand, having a server modifying the ACL without notifying the
>> kernel didn't sound right to me, specially because it has explicitly set
>> the FUSE_POSIX_ACL flag -- otherwise this code wouldn't be executed.  And
>> that's why I assumed it would be acceptable to have this optimisation:
>> because user-space asked the VFS to do permission checking *and* caching
>> ACLs.
>
> Your arguments make sense to me.
> Only it appears so simple so it feels like I am missing something.
> Why wasn't this implemented like that in the first place?

Yeah, maybe your right, maybe I'm missing something as well and there is a
good reason for not doing it.

I was going to CC Christian, but I see you did that already :-)

Maybe he remembers the reasons behind this while working on commit
facd61053cff ("fuse: fixes after adapting to new posix acl api").

Cheers,
-- 
Luís

      reply	other threads:[~2026-07-02  8:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 11:00 [PATCH] fuse: cache POSIX ACLs when setting them Luis Henriques
2026-07-01 11:39 ` Horst Birthelmer
2026-07-01 11:41 ` Amir Goldstein
2026-07-01 11:47   ` Horst Birthelmer
2026-07-01 12:24   ` Luis Henriques
2026-07-01 22:58     ` Amir Goldstein
2026-07-02  8:56       ` Luis Henriques [this message]

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=87o6gp7ot2.fsf@wotan.olymp \
    --to=luis@igalia.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=fuse-devel@lists.linux.dev \
    --cc=jlayton@kernel.org \
    --cc=kernel-dev@igalia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mharvey@jumptrading.com \
    --cc=miklos@szeredi.hu \
    --cc=sforshee@kernel.org \
    /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