On 19/04/13 10:17, Heiko Carstens wrote: > 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? > Since the size of statfs doesn't change I would not expect problems. However, recompiling code you might get additional warnings if the struct fields are used in signed integer comparisons. But I don't think this will result in a real problem given that all involved values are expected to be positive anyway. -Andreas- -- 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
