Re: [PATCH 2/2] fs: return EOPNOTSUPP from file_setattr/file_getattr syscalls

On Fri, Oct 10, 2025 at 12:05:04PM +0200, Andrey Albershteyn wrote:

On 2025-10-09 10:20:41, Darrick J. Wong wrote:

quoted

On Wed, Oct 08, 2025 at 02:44:18PM +0200, Andrey Albershteyn wrote:

quoted

These syscalls call to vfs_fileattr_get/set functions which return
ENOIOCTLCMD if filesystem doesn't support setting file attribute on an
inode. For syscalls EOPNOTSUPP would be more appropriate return error.

Signed-off-by: Andrey Albershteyn <aalbersh@kernel.org>
---
 fs/file_attr.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/file_attr.c b/fs/file_attr.c
index 460b2dd21a85..5e3e2aba97b5 100644
--- a/fs/file_attr.c
+++ b/fs/file_attr.c

@@ -416,6 +416,8 @@ SYSCALL_DEFINE5(file_getattr, int, dfd, const char __user *, filename,
 	}
 
 	error = vfs_fileattr_get(filepath.dentry, &fa);
+	if (error == -ENOIOCTLCMD)

Hrm.  Back in 6.17, XFS would return ENOTTY if you called ->fileattr_get
on a special file:

int
xfs_fileattr_get(
	struct dentry		*dentry,
	struct file_kattr	*fa)
{
	struct xfs_inode	*ip = XFS_I(d_inode(dentry));

	if (d_is_special(dentry))
		return -ENOTTY;
	...
}

Given that there are other fileattr_[gs]et implementations out there
that might return ENOTTY (e.g. fuse servers and other externally
maintained filesystems), I think both syscall functions need to check
for that as well:

	if (error == -ENOIOCTLCMD || error == -ENOTTY)
		return -EOPNOTSUPP;

Make sense (looks like ubifs, jfs and gfs2 also return ENOTTY for
special files), I haven't found ENOTTY being used for anything else
there

I'm folding this in.