All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <luis@igalia.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Dave Chinner <david@fromorbit.com>,
	 Bernd Schubert <bschubert@ddn.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>,  Jan Kara <jack@suse.cz>,
	 Matt Harvey <mharvey@jumptrading.com>,
	 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Valentin Volkl <valentin.volkl@cern.ch>,
	Laura Promberger <laura.promberger@cern.ch>
Subject: Re: [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes
Date: Wed, 19 Feb 2025 16:31:21 +0000	[thread overview]
Message-ID: <87a5ah521y.fsf@igalia.com> (raw)
In-Reply-To: <CAJfpegs-_sFPnMBwEa-2OSiaNriH6ZvEnM73vNZBiwzrSWFraw@mail.gmail.com> (Miklos Szeredi's message of "Wed, 19 Feb 2025 16:39:53 +0100")

On Wed, Feb 19 2025, Miklos Szeredi wrote:

> On Wed, 19 Feb 2025 at 12:23, Luis Henriques <luis@igalia.com> wrote:
>
>> +static int fuse_notify_update_epoch(struct fuse_conn *fc)
>> +{
>> +       struct fuse_mount *fm;
>> +       struct inode *inode;
>> +
>> +       inode = fuse_ilookup(fc, FUSE_ROOT_ID, &fm);
>> +       if (!inode) || !fm)
>> +               return -ENOENT;
>> +
>> +       iput(inode);
>> +       atomic_inc(&fc->epoch);
>> +       shrink_dcache_sb(fm->sb);
>
> This is just an optimization and could be racy, kicking out valid
> cache (harmlessly of course).  I'd leave it out of the first version.

OK, will do.

> There could be more than one fuse_mount instance.  Wondering if epoch
> should be per-fm not per-fc...

Good question.  Because the cache is shared among the several fuse_mount
instances the epoch may eventually affect all of them even if it's a
per-fm attribute.  But on the other hand, different mounts could focus on
a different set of filesystem subtrees so... yeah, I'll probably leave it
in fc for now while thinking about it some more.

>> @@ -204,6 +204,12 @@ static int fuse_dentry_revalidate(struct inode *dir, const struct qstr *name,
>>         int ret;
>>
>>         inode = d_inode_rcu(entry);
>> +       if (inode) {
>> +               fm = get_fuse_mount(inode);
>> +               if (entry->d_time < atomic_read(&fm->fc->epoch))
>> +                       goto invalid;
>> +       }
>
> Negative dentries need to be invalidated too.

Ack.

>> @@ -446,6 +452,12 @@ static struct dentry *fuse_lookup(struct inode *dir, struct dentry *entry,
>>                 goto out_err;
>>
>>         entry = newent ? newent : entry;
>> +       if (inode) {
>> +               struct fuse_mount *fm = get_fuse_mount(inode);
>> +               entry->d_time = atomic_read(&fm->fc->epoch);
>> +       } else {
>> +               entry->d_time = 0;
>> +       }
>
> Again, should do the same for positive and negative dentries.
>
> Need to read out fc->epoch before sending the request to the server,
> otherwise might get a stale dentry with an updated epoch.

Ah, good point.

> This also needs to be done in fuse_create_open(), create_new_entry()
> and fuse_direntplus_link().

Yeah I suspected there were a few other places where this would be
required.  I'll look closer into that.

Thanks a lot for your feedback, Miklos.  I'll work on this new approach,
so that I can send a real patch soon.

Cheers,
-- 
Luís

  reply	other threads:[~2025-02-19 16:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 13:32 [PATCH v6 0/2] fuse: allow notify_inval for all inodes Luis Henriques
2025-02-17 13:32 ` [PATCH v6 1/2] vfs: export invalidate_inodes() Luis Henriques
2025-02-18  0:39   ` Dave Chinner
2025-02-17 13:32 ` [PATCH v6 2/2] fuse: add new function to invalidate cache for all inodes Luis Henriques
2025-02-18  0:55   ` Dave Chinner
2025-02-18  9:15     ` Miklos Szeredi
2025-02-18 10:04       ` Luis Henriques
2025-02-18 10:34         ` Miklos Szeredi
2025-02-18 11:51           ` Luis Henriques
2025-02-18 14:26             ` Miklos Szeredi
2025-02-18 18:11               ` Luis Henriques
2025-02-18 22:05                 ` Dave Chinner
2025-02-19 11:23                   ` Luis Henriques
2025-02-19 15:39                     ` Miklos Szeredi
2025-02-19 16:31                       ` Luis Henriques [this message]
2025-02-18 21:29               ` Dave Chinner
2025-02-18 21:44       ` Dave Chinner
2025-02-18  9:07   ` Miklos Szeredi

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=87a5ah521y.fsf@igalia.com \
    --to=luis@igalia.com \
    --cc=brauner@kernel.org \
    --cc=bschubert@ddn.com \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=laura.promberger@cern.ch \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mharvey@jumptrading.com \
    --cc=miklos@szeredi.hu \
    --cc=valentin.volkl@cern.ch \
    --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.