linux-kernel - Re: [PATCH] fuse: add FOPEN_INVAL

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YrnHeqckLknFleud@redhat.com>
Date:   Mon, 27 Jun 2022 11:06:34 -0400
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Jiachen Zhang <zhangjiachen.jaycee@...edance.com>
Cc:     miklos@...redi.hu, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fuse: add FOPEN_INVAL_ATTR

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?

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?

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?

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
>