On Thu, Apr 18, 2013 at 03:10:18PM +0200, Kay Sievers wrote: > The definition of struct statfs::f_type needs a fix. s390 is the only > architecture in the kernel that uses an int and expects magic > constants lager than INT_MAX to fit into. > > A fix is needed to make Fedora boot on s390, it currently fails to do > so. Userspace does not want to add code to paper-over this issue. > > Some of the f_type magic constants results in a negative int, which is > propagated to a long inside of glibc; and then it will never match the > original value again. I just had look into the glibc code but couldn't find any (implicit) cast from int to long. Can you give a pointer to the code in glibc where this breaks? > Even coreutils cannot handle it: > #define RAMFS_MAGIC 0x858458f6 > # stat -f -c%t / > ffffffff858458f6 > > #define BTRFS_SUPER_MAGIC 0x9123683E > # stat -f -c%t /mnt > ffffffff9123683e Yes, stat is broken since it implicitly casts the f_type int to an (unsigned) long. In general I don't think anything will break if we change all ints in struct statfs and statfs64 from int to unsigned int in the kernel uapi header file and the copy in glibc. (klibc already uses only u32 for what the kernel thinks are signed fields). Andreas, do you think anything will break if we change this? -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
