[PATCH] fs: fix the missing export of vfs_statx() and vfs_fstatat()

[PATCH] fs: fix the missing export of vfs_statx() and vfs_fstatat()

[alexjlzheng]

From: Jinliang Zheng <alexjlzheng@tencent.com>

After commit 09f1bde4017e ("fs: move vfs_fstatat out of line"), the two
symbols vfs_statx() and vfs_fstatat() are no longer visible to the kernel
module.

The above patches does not explain why the export of these two symbols is
stopped, and exporting these two kernel symbols does not affect the
functionality of the above patch.

In fact, getting the length of a file in a kernel module is a useful
operation. For example, some kernel modules used for security hardening may
need to know the length of a file in order to read it into memory for
verification.

There is no reason to prohibit kernel module developers from doing this.
So this patch fixes that by reexporting vfs_statx() and vfs_fstatat().

Fixes: 09f1bde4017e ("fs: move vfs_fstatat out of line")
Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com>
---
 fs/stat.c          | 4 +++-
 include/linux/fs.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/stat.c b/fs/stat.c
index f95c1dc3eaa4..e844a1a076d7 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -338,7 +338,7 @@ static int vfs_statx_fd(int fd, int flags, struct kstat *stat,
  *
  * 0 will be returned on success, and a -ve error code if unsuccessful.
  */
-static int vfs_statx(int dfd, struct filename *filename, int flags,
+int vfs_statx(int dfd, struct filename *filename, int flags,
 	      struct kstat *stat, u32 request_mask)
 {
 	struct path path;
@@ -361,6 +361,7 @@ static int vfs_statx(int dfd, struct filename *filename, int flags,
 	}
 	return error;
 }
+EXPORT_SYMBOL(vfs_statx);
 
 int vfs_fstatat(int dfd, const char __user *filename,
 			      struct kstat *stat, int flags)
@@ -377,6 +378,7 @@ int vfs_fstatat(int dfd, const char __user *filename,
 
 	return ret;
 }
+EXPORT_SYMBOL(vfs_fstatat);
 
 #ifdef __ARCH_WANT_OLD_STAT
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b085f161ed22..c9497da6b459 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3550,6 +3550,8 @@ extern const struct inode_operations simple_symlink_inode_operations;
 
 extern int iterate_dir(struct file *, struct dir_context *);
 
+int vfs_statx(int dfd, struct filename *filename, int flags,
+		struct kstat *stat, u32 request_mask);
 int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
 		int flags);
 int vfs_fstat(int fd, struct kstat *stat);
-- 
2.49.0

Re: [PATCH] fs: fix the missing export of vfs_statx() and vfs_fstatat()

[Jan Kara]

CCed Christoph who was the original author of the patch.

On Wed 18-06-25 20:14:29, alexjlzheng@gmail.com wrote:
> From: Jinliang Zheng <alexjlzheng@tencent.com>
> 
> After commit 09f1bde4017e ("fs: move vfs_fstatat out of line"), the two
> symbols vfs_statx() and vfs_fstatat() are no longer visible to the kernel
> module.
> 
> The above patches does not explain why the export of these two symbols is
> stopped, and exporting these two kernel symbols does not affect the
> functionality of the above patch.
> 
> In fact, getting the length of a file in a kernel module is a useful
> operation. For example, some kernel modules used for security hardening may
> need to know the length of a file in order to read it into memory for
> verification.
> 
> There is no reason to prohibit kernel module developers from doing this.
> So this patch fixes that by reexporting vfs_statx() and vfs_fstatat().
> 
> Fixes: 09f1bde4017e ("fs: move vfs_fstatat out of line")
> Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com>

Well, we don't export symbols just because they might be useful. Usually we
require *in tree* users of the interface to export a symbol. You apparently
have an out of tree module that was using these functions and 09f1bde4017e
broke it. Keeping things out of tree is your choice but why should we care
and support you in working outside of a community?

								Honza

> ---
>  fs/stat.c          | 4 +++-
>  include/linux/fs.h | 2 ++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/stat.c b/fs/stat.c
> index f95c1dc3eaa4..e844a1a076d7 100644
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -338,7 +338,7 @@ static int vfs_statx_fd(int fd, int flags, struct kstat *stat,
>   *
>   * 0 will be returned on success, and a -ve error code if unsuccessful.
>   */
> -static int vfs_statx(int dfd, struct filename *filename, int flags,
> +int vfs_statx(int dfd, struct filename *filename, int flags,
>  	      struct kstat *stat, u32 request_mask)
>  {
>  	struct path path;
> @@ -361,6 +361,7 @@ static int vfs_statx(int dfd, struct filename *filename, int flags,
>  	}
>  	return error;
>  }
> +EXPORT_SYMBOL(vfs_statx);
>  
>  int vfs_fstatat(int dfd, const char __user *filename,
>  			      struct kstat *stat, int flags)
> @@ -377,6 +378,7 @@ int vfs_fstatat(int dfd, const char __user *filename,
>  
>  	return ret;
>  }
> +EXPORT_SYMBOL(vfs_fstatat);
>  
>  #ifdef __ARCH_WANT_OLD_STAT
>  
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index b085f161ed22..c9497da6b459 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3550,6 +3550,8 @@ extern const struct inode_operations simple_symlink_inode_operations;
>  
>  extern int iterate_dir(struct file *, struct dir_context *);
>  
> +int vfs_statx(int dfd, struct filename *filename, int flags,
> +		struct kstat *stat, u32 request_mask);
>  int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
>  		int flags);
>  int vfs_fstat(int fd, struct kstat *stat);
> -- 
> 2.49.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] fs: fix the missing export of vfs_statx() and vfs_fstatat()

[Christoph Hellwig]

On Wed, Jun 18, 2025 at 05:51:55PM +0200, Jan Kara wrote:
> Well, we don't export symbols just because they might be useful. Usually we
> require *in tree* users of the interface to export a symbol. You apparently
> have an out of tree module that was using these functions and 09f1bde4017e
> broke it. Keeping things out of tree is your choice but why should we care
> and support you in working outside of a community?

Yes, of course.

I'm pretty annoyed that we get a lot of these silly exports, mostly from
big companies in the android space.  I'm not sure if this is elaborate
trolling, or if their training about Linux development is really so
spectacularly bad.