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] [day] [month] [year] [list]
Message-ID: <CAFQAk7jgV1EkLK120tPkcG0MvupRMLQcvLNj8aP-=45nymMnQw@mail.gmail.com>
Date:   Tue, 28 Jun 2022 13:14:21 +0800
From:   Jiachen Zhang <zhangjiachen.jaycee@...edance.com>
To:     Vivek Goyal <vgoyal@...hat.com>
Cc:     Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] fuse: add FOPEN_INVAL_ATTR

On Mon, Jun 27, 2022 at 11:06 PM Vivek Goyal <vgoyal@...hat.com> wrote:
>
> On Wed, Jun 08, 2022 at 06:42:02PM +0800, Jiachen Zhang wrote:
> > So that the fuse daemon can ask kernel to invalidate the attr cache on file
> > open.
>
> Will be great if there was a proper context around this. Without any
> explanation, how one is supposed to understand how this is useful.
>
> By going through other email threads, looks like, with writeback
> cache enabled, you want to invalidate attr cache and data cache
> when file is opened next time. Right?


Hi Vivek,

Yes, exactly. This patch is supposed to be a supplement to the
writeback_cache consistency enhancement patch [1]. Sorry for the lack
of explanation. I think I will send this and the enhancement patch as
a patchset later after there is more comments and discussions.

>
> IOW, when file is closed, its changes will be flushed out. And when
> file is reopened, server somehow is supposed to determine if file
> has changed (on server by another client) and based on that determine
> whether to invalidate attr and data cache on next open?

Yes, to achieve this so-called close-to-open consistency, this patch
gives a knod to FUSE server handler to invalidate attributes cache on
file open.

>
> Even without that, on next open, it probably makes sense to being
> invalidate attr cache. We have notion to invalidate data cache. So
> it will be kind of odd that we can invalidate data but not attrs
> on next open. Am I understanding it right?

Yes, Exactly. It could also be used for immediate attr invalidation in
write-through mode.

[1] https://lore.kernel.org/linux-fsdevel/20220624055825.29183-1-zhangjiachen.jaycee@bytedance.com/

Thanks,
Jiachen

>
> Thanks
> Vivek
>
> >
> > Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@...edance.com>
> > ---
> >  fs/fuse/file.c            | 4 ++++
> >  include/uapi/linux/fuse.h | 2 ++
> >  2 files changed, 6 insertions(+)
> >
> > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> > index fdcec3aa7830..9609d13ec351 100644
> > --- a/fs/fuse/file.c
> > +++ b/fs/fuse/file.c
> > @@ -213,6 +213,10 @@ void fuse_finish_open(struct inode *inode, struct file *file)
> >               file_update_time(file);
> >               fuse_invalidate_attr_mask(inode, FUSE_STATX_MODSIZE);
> >       }
> > +
> > +     if (ff->open_flags & FOPEN_INVAL_ATTR)
> > +             fuse_invalidate_attr(inode);
> > +
> >       if ((file->f_mode & FMODE_WRITE) && fc->writeback_cache)
> >               fuse_link_write_file(file);
> >  }
> > diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> > index d6ccee961891..0b0b7d308ddb 100644
> > --- a/include/uapi/linux/fuse.h
> > +++ b/include/uapi/linux/fuse.h
> > @@ -301,6 +301,7 @@ struct fuse_file_lock {
> >   * FOPEN_CACHE_DIR: allow caching this directory
> >   * FOPEN_STREAM: the file is stream-like (no file position at all)
> >   * FOPEN_NOFLUSH: don't flush data cache on close (unless FUSE_WRITEBACK_CACHE)
> > + * FOPEN_INVAL_ATTR: invalidate the attr cache on open
> >   */
> >  #define FOPEN_DIRECT_IO              (1 << 0)
> >  #define FOPEN_KEEP_CACHE     (1 << 1)
> > @@ -308,6 +309,7 @@ struct fuse_file_lock {
> >  #define FOPEN_CACHE_DIR              (1 << 3)
> >  #define FOPEN_STREAM         (1 << 4)
> >  #define FOPEN_NOFLUSH                (1 << 5)
> > +#define FOPEN_INVAL_ATTR     (1 << 6)
> >
> >  /**
> >   * INIT request/reply flags
> > --
> > 2.20.1
> >
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ