Add support 32 bit FS_IOC32_{GET|SET}FLAGS compat ioctls

[ColinIanKing]

We need 32 bit userspace FS_IOC32_GETFLAGS and FS_IOC32_SETFLAGS
compat ioctls for systems such as powerpc64. We use the normal
compat ioctl idiom as used by a variety of file systems to provide
this support.

Signed-off-by: Colin Ian King [email protected]

[behlendorf]

It looks like the other Linux filesystems return -ENOIOCTLCMD in this case.

[ColinIanKing]

autofs4, btrfs, ceph, cifs, hfsplus, jffs2, jffs, xfs return -ENOTTY, ncpfs returns -EINVAL, and ubifs returns -ENOTTY and also -ENOIOCTLCMD. The rest return -ENOIOCTLCMD. So, I'm not sure what the correct error return is. According to ioctl(2) manual, -ENOTTY seems like the documented return for a command that is not recognised for the specific object being operated on. So shall we leave it as -ENOTTY for now and not change that functionality in this particular commit?

[behlendorf]

Interesting, I was just basing my comment off what ext2/3/4 does. I'm glad you took a bigger sample. Yes, I'm OK leaving this as -ENOTTY. It can always be changed if needed in a latter commit if needed.

[behlendorf]

There's going to be an identical problem to this in zvol_compat_ioctl() where ioctl's for volumes are handled (BLKFLSBUF, BLKZNAME). Let's tackle both of this cases in the same commit since they share a root cause.

[ColinIanKing]

How do you want to play this? I'm running out of time on this today, it's rather late now UK time. I'm happy if you drop this patch and fix it appropriately for the zvol_compat_ioctl case and the more standard error return. I can then give it a spin first thing Friday morning. Or I can sort it out tomorrow. I'm easy either way.

[behlendorf]

Sure, if you like I can open a new PR which makes the corresponding zvol_compat_ioctl() change. I don't have a test setup handy to verify it resolves the compat issue so you'll need to verify that Friday morning.

[behlendorf]

And since your original patch then doesn't require any changes we could just leave the zvol_compat_ioctl() fixes for another patch. Although we should sort it out now while the issue is well understand and you're setup to verify it.

[ColinIanKing]

Lets go for that zvol_compat_ioctl() as another patch which I can test sooner than later 'cos I've got access to some kit for another few more days. I have a window of a few more days and then we go for final freeze on fixes for 16.04.

[behlendorf]

@ColinIanKing sounds good. I'll open a new PR with the zvol_compat_ioctl() fix in the next few hours so you should have it in the morning. If you have a list of other issues like this you've hit by all means let me know, I may be able to point you to fixes already in master.

[behlendorf]

@ColinIanKing I took a closer look at zvol_compat_ioctl() and it doesn't look like there will be an issue. The generic Linux blkdev ioctl handler already deals with most of the standard ioctls(). The two cases that remain are:

• BLKZNAME which is ZFS specific and takes a fixed length character array so there's no need for a compat version. And,
• BLKFLSBUF which is defined by the kernel and implemented by ZFS, but it's just a command without arguments so again there is no issue.

I've merged your proposed patch to master, and we'll cherry-pick it back on to the release branch.

f7b939b Add support 32 bit FS_IOC32_{GET|SET}FLAGS compat ioctls