On Tue, Nov 26, 2013 at 11:00:13PM -0500, Theodore Ts'o wrote: > On Tue, Nov 26, 2013 at 05:01:41PM -0800, Darrick J. Wong wrote: > > > 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. > > This is a mistake that was made a long, LONG, LONG time ago. And so > there are huge numbers of userspace programs which are using an int, > and we change it to be a long, it will break those userspace programs > for ALL platforms where sizeof(int) != sizeof(long). This includes all > 64-bit x86 systems, for which there are quite a few. :-) > > Yes, it's unfortunate that programs that programs that try to use a > long are breaking on 64-bit big endian machines, but (a) there are > much fewer of them, and (b) they are only breaking on big endian > machines, as opposed the much bigger class of userspace programs which > would break on the proposed change for ALL 64-bit platforms, including > x86-64. And like it or not, there are a lot more linux machines > running x86-64, compared to those running linux on big-endian PowerPC. > (Of course, the little-endian ppc machines which IBM is now pushing > for Linux in data centers will be just fine. :-P) I agree that big endian 64-bit is not the majority of the machines, but still such machines exist. We should just not ignore them. And in my case the problem arises on s390x, and I am not aware of a little endian s390 platforms. > If people really cared, we could allocate a new ioctl codepoint, and > then teach the kernel to support the new ioctl number, and then > gradually change userspace to first try the new ioctl, and if that > failed go back to the old one. The coversion progress would take 5-10 > years (there are still sites running RHEL 3, and RHEL 4 after all), > and it wouldn't help existing userspace programs, that would still be > using the old code point. Hence my recommendation that the path of > least resistence is to fix the kernel FUSE code, instead of trying to > change the world. In my case, I am *not* talking about FUSE code, but programs using this ioctl from userland. Changing the kernel FUSE code won't fix the problem I reported. People who do the things correctly lookup the argument type in <linux/fs.h>, they see it's a long and then use a long in their code. And they are right. The bare minimum would be to add a comment close to the definition to explain to use an int and not a long. -- 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
