[v4,46/68] cachefiles: Mark a backing file in use with an inode flag

Use an inode flag, S_KERNEL_FILE, to mark that a backing file is in use by
the kernel to prevent cachefiles or other kernel services from interfering
with that file.

Using S_SWAPFILE instead isn't really viable as that has other effects in
the I/O paths.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-cachefs@redhat.com
Link: https://lore.kernel.org/r/163819642273.215744.6414248677118690672.stgit@warthog.procyon.org.uk/ # v1
Link: https://lore.kernel.org/r/163906943215.143852.16972351425323967014.stgit@warthog.procyon.org.uk/ # v2
Link: https://lore.kernel.org/r/163967154118.1823006.13227551961786743991.stgit@warthog.procyon.org.uk/ # v3
---

 fs/cachefiles/internal.h |    2 ++
 fs/cachefiles/namei.c    |   35 +++++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)

On Wed, 2021-12-22 at 23:25 +0000, David Howells wrote:
> Use an inode flag, S_KERNEL_FILE, to mark that a backing file is in use by
> the kernel to prevent cachefiles or other kernel services from interfering
> with that file.
> 
> Using S_SWAPFILE instead isn't really viable as that has other effects in
> the I/O paths.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: linux-cachefs@redhat.com
> Link: https://lore.kernel.org/r/163819642273.215744.6414248677118690672.stgit@warthog.procyon.org.uk/ # v1
> Link: https://lore.kernel.org/r/163906943215.143852.16972351425323967014.stgit@warthog.procyon.org.uk/ # v2
> Link: https://lore.kernel.org/r/163967154118.1823006.13227551961786743991.stgit@warthog.procyon.org.uk/ # v3
> ---
> 
>  fs/cachefiles/internal.h |    2 ++
>  fs/cachefiles/namei.c    |   35 +++++++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/fs/cachefiles/internal.h b/fs/cachefiles/internal.h
> index 01071e7a7c02..7c67a70a3dff 100644
> --- a/fs/cachefiles/internal.h
> +++ b/fs/cachefiles/internal.h
> @@ -187,6 +187,8 @@ extern struct kmem_cache *cachefiles_object_jar;
>  /*
>   * namei.c
>   */
> +extern void cachefiles_unmark_inode_in_use(struct cachefiles_object *object,
> +					   struct file *file);
>  extern struct dentry *cachefiles_get_directory(struct cachefiles_cache *cache,
>  					       struct dentry *dir,
>  					       const char *name,
> diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c
> index 11a33209ab5f..db60a671c3fc 100644
> --- a/fs/cachefiles/namei.c
> +++ b/fs/cachefiles/namei.c
> @@ -31,6 +31,18 @@ static bool __cachefiles_mark_inode_in_use(struct cachefiles_object *object,
>  	return can_use;
>  }
>  
> +static bool cachefiles_mark_inode_in_use(struct cachefiles_object *object,
> +					 struct dentry *dentry)
> +{
> +	struct inode *inode = d_backing_inode(dentry);
> +	bool can_use;
> +
> +	inode_lock(inode);
> +	can_use = __cachefiles_mark_inode_in_use(object, dentry);
> +	inode_unlock(inode);
> +	return can_use;
> +}
> +
>  /*
>   * Unmark a backing inode.  The caller must hold the inode lock.
>   */
> @@ -43,6 +55,29 @@ static void __cachefiles_unmark_inode_in_use(struct cachefiles_object *object,
>  	trace_cachefiles_mark_inactive(object, inode);
>  }
>  
> +/*
> + * Unmark a backing inode and tell cachefilesd that there's something that can
> + * be culled.
> + */
> +void cachefiles_unmark_inode_in_use(struct cachefiles_object *object,
> +				    struct file *file)
> +{
> +	struct cachefiles_cache *cache = object->volume->cache;
> +	struct inode *inode = file_inode(file);
> +
> +	if (inode) {
> +		inode_lock(inode);
> +		__cachefiles_unmark_inode_in_use(object, file->f_path.dentry);
> +		inode_unlock(inode);
> +
> +		if (!test_bit(CACHEFILES_OBJECT_USING_TMPFILE, &object->flags)) {
> +			atomic_long_add(inode->i_blocks, &cache->b_released);
> +			if (atomic_inc_return(&cache->f_released))
> +				cachefiles_state_changed(cache);
> +		}
> +	}
> +}
> +
>  /*
>   * get a subdirectory
>   */
> 
> 

Probably, this patch should be merged with #38. The commit logs are the
same, and they are at least somewhat related.

Jeff Layton <jlayton@kernel.org> wrote:

> Probably, this patch should be merged with #38. The commit logs are the
> same, and they are at least somewhat related.

That's not so simple, unfortunately.  Patch 46 requires bits of patches 43 and
45 in addition to patch 38 and patch 39 depends on patch 38.

David