[PATCH] fs: unexport ioctl_getflags

[PATCH] fs: unexport ioctl_getflags

[Christoph Hellwig]

No modular users, nor should there be any for a dispatcher like this.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/file_attr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/file_attr.c b/fs/file_attr.c
index 1dcec88c0680..63d62742fbb1 100644
--- a/fs/file_attr.c
+++ b/fs/file_attr.c
@@ -316,7 +316,6 @@ int ioctl_getflags(struct file *file, unsigned int __user *argp)
 		err = put_user(fa.flags, argp);
 	return err;
 }
-EXPORT_SYMBOL(ioctl_getflags);
 
 int ioctl_setflags(struct file *file, unsigned int __user *argp)
 {
-- 
2.47.3

Re: [PATCH] fs: unexport ioctl_getflags

[Johannes Thumshirn]

Looks good,

Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>

Re: [PATCH] fs: unexport ioctl_getflags

[Darrick J. Wong]

On Tue, Nov 18, 2025 at 08:09:41AM +0100, Christoph Hellwig wrote:
> No modular users, nor should there be any for a dispatcher like this.

Does the same logic apply to the EXPORT_SYMBOLs of ioctl_setflags /
ioctl_fs[gs]etxattr?

--D

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/file_attr.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/fs/file_attr.c b/fs/file_attr.c
> index 1dcec88c0680..63d62742fbb1 100644
> --- a/fs/file_attr.c
> +++ b/fs/file_attr.c
> @@ -316,7 +316,6 @@ int ioctl_getflags(struct file *file, unsigned int __user *argp)
>  		err = put_user(fa.flags, argp);
>  	return err;
>  }
> -EXPORT_SYMBOL(ioctl_getflags);
>  
>  int ioctl_setflags(struct file *file, unsigned int __user *argp)
>  {
> -- 
> 2.47.3
> 
> 

Re: [PATCH] fs: unexport ioctl_getflags

[Christoph Hellwig]

On Tue, Nov 18, 2025 at 07:59:13AM -0800, Darrick J. Wong wrote:
> On Tue, Nov 18, 2025 at 08:09:41AM +0100, Christoph Hellwig wrote:
> > No modular users, nor should there be any for a dispatcher like this.
> 
> Does the same logic apply to the EXPORT_SYMBOLs of ioctl_setflags /
> ioctl_fs[gs]etxattr?

Yes.

Re: [PATCH] fs: unexport ioctl_getflags

[Al Viro]

On Tue, Nov 18, 2025 at 08:09:41AM +0100, Christoph Hellwig wrote:
> No modular users, nor should there be any for a dispatcher like this.

... and AFAICS there never had been any, so it shouldn't have been
exported in the first place.

Re: [PATCH] fs: unexport ioctl_getflags

[Christoph Hellwig]

On Wed, Nov 19, 2025 at 12:30:04AM +0000, Al Viro wrote:
> On Tue, Nov 18, 2025 at 08:09:41AM +0100, Christoph Hellwig wrote:
> > No modular users, nor should there be any for a dispatcher like this.
> 
> ... and AFAICS there never had been any, so it shouldn't have been
> exported in the first place.

Good question.  It looks like Andrey added them when moving to the
code to a new file despite that commit claiming to be pure refactoring.

Re: [PATCH] fs: unexport ioctl_getflags

[Christian Brauner]

On Tue, 18 Nov 2025 08:09:41 +0100, Christoph Hellwig wrote:
> No modular users, nor should there be any for a dispatcher like this.
> 
> 

Applied to the vfs-6.19.misc branch of the vfs/vfs.git tree.
Patches in the vfs-6.19.misc branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-6.19.misc

[1/1] fs: unexport ioctl_getflags
      https://git.kernel.org/vfs/vfs/c/87f58c6cc372

Re: [PATCH] fs: unexport ioctl_getflags

[Christoph Hellwig]

On Wed, Nov 19, 2025 at 09:42:53AM +0100, Christian Brauner wrote:
> On Tue, 18 Nov 2025 08:09:41 +0100, Christoph Hellwig wrote:
> > No modular users, nor should there be any for a dispatcher like this.
> > 
> > 

I was going to send a patch doing all the exports in file_attr.c in one
go.  I can do that incrementally, but I think it would be a tad
cleaner.

Re: [PATCH] fs: unexport ioctl_getflags

[Christian Brauner]

On Wed, Nov 19, 2025 at 10:01:00AM +0100, Christoph Hellwig wrote:
> On Wed, Nov 19, 2025 at 09:42:53AM +0100, Christian Brauner wrote:
> > On Tue, 18 Nov 2025 08:09:41 +0100, Christoph Hellwig wrote:
> > > No modular users, nor should there be any for a dispatcher like this.
> > > 
> > > 
> 
> I was going to send a patch doing all the exports in file_attr.c in one
> go.  I can do that incrementally, but I think it would be a tad
> cleaner.

Sure, send it it one patch. I can update.

Re: [PATCH] fs: unexport ioctl_getflags

[Christian Brauner]

On Tue, Nov 18, 2025 at 08:09:41AM +0100, Christoph Hellwig wrote:
> No modular users, nor should there be any for a dispatcher like this.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---

Ideally we'd be able to catch unnecessary exports automatically.
Which would also be nice because it would mean that we could enforce
automatic removal of unused exports. I'm pretty sure we have a bunch of
them without realizing it.

Re: [PATCH] fs: unexport ioctl_getflags

[Christoph Hellwig]

On Wed, Nov 19, 2025 at 09:45:46AM +0100, Christian Brauner wrote:
> On Tue, Nov 18, 2025 at 08:09:41AM +0100, Christoph Hellwig wrote:
> > No modular users, nor should there be any for a dispatcher like this.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> 
> Ideally we'd be able to catch unnecessary exports automatically.
> Which would also be nice because it would mean that we could enforce
> automatic removal of unused exports. I'm pretty sure we have a bunch of
> them without realizing it.

The problem with that is that it is so configuration dependent.

Also there are occasional cases where we add exports in one merge window
for the users to appear in the next one to reduce cross-subsystem
dependencies, so we'd nee to do this manually.

Maybe just having CONFIG_TRIM_UNUSED_KSYMS outout the unused symbols
in a log file and manually looking over that for various allmodconfigs
might be a good start.