Re: [PATCH 1/7] fs: export invalidate_inodes()

[Jan Kara]

On Fri 07-03-25 08:49:25, Kent Overstreet wrote:
> Needed in bcachefs for implementing blk_holder_ops.mark_dead, since we
> can't use the standard fs holder ops (whicth assume a single block device
> filesystem).
> 
> Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
> Cc: Christian Brauner <brauner@xxxxxxxxxx>
> Cc: Jan Kara <jack@xxxxxxx>
> Signed-off-by: Kent Overstreet <kent.overstreet@xxxxxxxxx>

Please use evict_inodes(). It is exactly the same and is actually already
exported. Since you are the second one in last month to ask for this let's
clean this up [1].

								Honza

[1] https://lore.kernel.org/20250307144318.28120-2-jack@xxxxxxx

> ---
>  fs/inode.c         | 1 +
>  fs/internal.h      | 1 -
>  include/linux/fs.h | 1 +
>  3 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index 5587aabdaa5e..6364779a7006 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -939,6 +939,7 @@ void invalidate_inodes(struct super_block *sb)
>  
>  	dispose_list(&dispose);
>  }
> +EXPORT_SYMBOL_GPL(invalidate_inodes);
>  
>  /*
>   * Isolate the inode from the LRU in preparation for freeing it.
> diff --git a/fs/internal.h b/fs/internal.h
> index e7f02ae1e098..7cb515cede3f 100644
> --- a/fs/internal.h
> +++ b/fs/internal.h
> @@ -207,7 +207,6 @@ bool in_group_or_capable(struct mnt_idmap *idmap,
>   * fs-writeback.c
>   */
>  extern long get_nr_dirty_inodes(void);
> -void invalidate_inodes(struct super_block *sb);
>  
>  /*
>   * dcache.c
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index be3ad155ec9f..5196317598ac 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3251,6 +3251,7 @@ extern void unlock_new_inode(struct inode *);
>  extern void discard_new_inode(struct inode *);
>  extern unsigned int get_next_ino(void);
>  extern void evict_inodes(struct super_block *sb);
> +extern void invalidate_inodes(struct super_block *sb);
>  void dump_mapping(const struct address_space *);
>  
>  /*
> -- 
> 2.47.2
> 
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR