forge/linux-pinenote
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
linux-pinenote/arch/s390/include/uapi/asm/statfs.h

51 lines
995 B
C
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
/*
* S390 version
*
* Derived from "include/asm-i386/statfs.h"
*/
#ifndef _S390_STATFS_H
#define _S390_STATFS_H
S390: Update comments about why we don't use <asm-generic/statfs.h> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
2008-09-01 14:12:51 +01:00
/*
* We can't use <asm-generic/statfs.h> because in 64-bit mode
* we mix ints of different sizes in our struct statfs.
*/
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
#ifndef __KERNEL_STRICT_NAMES
#include <linux/types.h>
typedef __kernel_fsid_t fsid_t;
#endif
struct statfs {
s390/uapi: 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 of sign extension when assignment to a long value happens. This patch changes the s390 uapi struct stafs[64] definition in the kernel to contain only unsigned values. This was true for 32 bit builds anyway, since we use the generic uapi header file in that case. So lets not include conditionally the generic uapi header file but have the s390 implementation completely independent. Also fix the types of struct compat_stafs to match reality and move the definition of struct compat_statfs64 to asm/compat.h since it is not part of the api. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-04-22 10:41:27 +02:00
unsigned int f_type;
unsigned int f_bsize;
unsigned long f_blocks;
unsigned long f_bfree;
unsigned long f_bavail;
unsigned long f_files;
unsigned long f_ffree;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
__kernel_fsid_t f_fsid;
s390/uapi: 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 of sign extension when assignment to a long value happens. This patch changes the s390 uapi struct stafs[64] definition in the kernel to contain only unsigned values. This was true for 32 bit builds anyway, since we use the generic uapi header file in that case. So lets not include conditionally the generic uapi header file but have the s390 implementation completely independent. Also fix the types of struct compat_stafs to match reality and move the definition of struct compat_statfs64 to asm/compat.h since it is not part of the api. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-04-22 10:41:27 +02:00
unsigned int f_namelen;
unsigned int f_frsize;
unsigned int f_flags;
unsigned int f_spare[4];
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
};
struct statfs64 {
s390/uapi: 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 of sign extension when assignment to a long value happens. This patch changes the s390 uapi struct stafs[64] definition in the kernel to contain only unsigned values. This was true for 32 bit builds anyway, since we use the generic uapi header file in that case. So lets not include conditionally the generic uapi header file but have the s390 implementation completely independent. Also fix the types of struct compat_stafs to match reality and move the definition of struct compat_statfs64 to asm/compat.h since it is not part of the api. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-04-22 10:41:27 +02:00
unsigned int f_type;
unsigned int f_bsize;
s390/uapi: fix struct statfs64 definition With b8668fd0a7e1b59f "s390/uapi: change struct statfs[64] member types to unsigned values" the size of a couple of struct statfs64 member got incorrectly changed from 64 to 32 bit for 32 bit builds. Fix this by changing the type of couple of struct statfs64 members from unsigned long to unsigned long long. The definition of struct compat_statfs64 was correct however. Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-21 17:31:10 +01:00
unsigned long long f_blocks;
unsigned long long f_bfree;
unsigned long long f_bavail;
unsigned long long f_files;
unsigned long long f_ffree;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
__kernel_fsid_t f_fsid;
s390/uapi: 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 of sign extension when assignment to a long value happens. This patch changes the s390 uapi struct stafs[64] definition in the kernel to contain only unsigned values. This was true for 32 bit builds anyway, since we use the generic uapi header file in that case. So lets not include conditionally the generic uapi header file but have the s390 implementation completely independent. Also fix the types of struct compat_stafs to match reality and move the definition of struct compat_statfs64 to asm/compat.h since it is not part of the api. Reported-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-04-22 10:41:27 +02:00
unsigned int f_namelen;
unsigned int f_frsize;
unsigned int f_flags;
unsigned int f_spare[4];
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
};
#endif
Reference in a new issue Copy permalink