Re: Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, Nov 26, 2013 at 09:05:59PM +0100, Aurelien Jarno wrote:
> Hi,
> 
> If I understand correctly how ioctl declarations works, FS_IOC_GETFLAGS
> and FS_IOC_SETFLAGS ioctls take a pointer to a long argument, at least
> according to include/uapi/linux/fs.h:
> 
> | #define FS_IOC_GETFLAGS                 _IOR('f', 1, long)
> | #define FS_IOC_SETFLAGS                 _IOW('f', 2, long)
> 
> Not also the 32-bit compat versions of the ioctls takes an int:
> 
> | #define FS_IOC32_GETFLAGS               _IOR('f', 1, int)
> | #define FS_IOC32_SETFLAGS               _IOW('f', 2, int)
> 
> However on the kernel side, all the filesystem interpret these values as
> an int. For example in fs/ext4/ioctl.c:
> 
> |        unsigned int flags;
> | ...
> |                 return put_user(flags, (int __user *) arg);
> | ...
> |                 if (get_user(flags, (int __user *) arg))
> | ...
> 
> Most of the userland code seems to pass an int to this ioctl, but a few
> others (e.g.: bup, libexplain) passes a long. While it doesn't make a
> difference on little endian machines, it does make a difference on
> 64-bit big endian machines.
> 
> Could you please tell me if I am wrong in my analysis or if there is a
> actually real problem?

It also causes problems with FUSE, because the kernel fuse driver expects to be
able to transfer a ulong to and from userspace, but chattr & friends only
allocate an int on the stack, so stack mashing seems to happen.

I complained to tytso about it on linux-ext4 a while ago, he suggested
special-casing fuse... I haven't gotten around to doing that.

--D
> 
> Thanks,
> Aurelien
> 
> -- 
> Aurelien Jarno	                        GPG: 1024D/F1BCDB73
> aurelien@aurel32.net                 http://www.aurel32.net