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@xxxxxxxxxxx http://www.aurel32.net
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
