On Fri, Apr 19, 2013 at 02:23:59PM +0200, Kay Sievers wrote:
> On Fri, Apr 19, 2013 at 2:16 PM, Martin Schwidefsky
> <schwidefsky@xxxxxxxxxx> wrote:
> > On Fri, 19 Apr 2013 13:44:53 +0200 Kay Sievers <kay@xxxxxxxx> wrote:
> >> It's pretty confusing to sort out such issues in userspace, and it
> >> would be nice if it could be fixed to work without weird casting.
> >
> > Well, the easiest fix seem to be to convert the "int f_type" to an
> > "unsigned int f_type".
>
> That would be nice if that is possible, yeah.
...and the patch below for glibc:
>From 686164e6dc2b7b57d853b64b34cfa752fd9d3ae5 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Date: Mon, 22 Apr 2013 14:14:34 +0200
Subject: [PATCH] s390: change struct statfs[64] member types to unsigned
values
Kay Sievers reported that coreutils' stat tool has a problem with
s390's statfs[64] definition:
> 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.
[...]
> 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
The bug is caused by an implicit sign extension within the stat tool:
out_uint_x (pformat, prefix_len, statfsbuf->f_type);
where the format finally will be "%lx".
A similar problem can be found in the 'tail' tool.
s390 is the only architecture which has an int type f_type member in
struct statfs[64]. Other architectures have either unsigned ints or
long values, so that the problem doesn't occur there.
Therefore change the type of the f_type member to unsigned int, so
that we get zero extension instead sign extension when assignment to
a long value happens.
Reported-by: Kay Sievers <kay@xxxxxxxx>
Signed-off-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
---
sysdeps/unix/sysv/linux/s390/bits/statfs.h | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sysdeps/unix/sysv/linux/s390/bits/statfs.h b/sysdeps/unix/sysv/linux/s390/bits/statfs.h
index ff54607..91dde15 100644
--- a/sysdeps/unix/sysv/linux/s390/bits/statfs.h
+++ b/sysdeps/unix/sysv/linux/s390/bits/statfs.h
@@ -23,8 +23,8 @@
struct statfs
{
- int f_type;
- int f_bsize;
+ unsigned int f_type;
+ unsigned int f_bsize;
#ifndef __USE_FILE_OFFSET64
__fsblkcnt_t f_blocks;
__fsblkcnt_t f_bfree;
@@ -39,27 +39,27 @@ struct statfs
__fsfilcnt64_t f_ffree;
#endif
__fsid_t f_fsid;
- int f_namelen;
- int f_frsize;
- int f_flags;
- int f_spare[4];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_flags;
+ unsigned int f_spare[4];
};
#ifdef __USE_LARGEFILE64
struct statfs64
{
- int f_type;
- int f_bsize;
+ unsigned int f_type;
+ unsigned int f_bsize;
__fsblkcnt64_t f_blocks;
__fsblkcnt64_t f_bfree;
__fsblkcnt64_t f_bavail;
__fsfilcnt64_t f_files;
__fsfilcnt64_t f_ffree;
__fsid_t f_fsid;
- int f_namelen;
- int f_frsize;
- int f_flags;
- int f_spare[4];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_flags;
+ unsigned int f_spare[4];
};
#endif
--
1.7.12.4
--
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
