summaryrefslogtreecommitdiffstats
path: root/include/uapi/asm-generic/statfs.h
diff options
context:
space:
mode:
authorKees Cook <kees+treewide@kernel.org>2026-09-02 15:31:14 -0700
committerKees Cook <kees@kernel.org>2026-09-04 21:37:00 -0700
commit3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d (patch)
treec65086f9bdcd48c6360fb7cb4598bca084da1f32 /include/uapi/asm-generic/statfs.h
downloadlinux-stable-3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d.tar.gz
linux-stable-3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d.zip
treewide: refresh kmalloc_obj() conversionsgrafted
This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Diffstat (limited to 'include/uapi/asm-generic/statfs.h')
-rw-r--r--include/uapi/asm-generic/statfs.h84
1 files changed, 84 insertions, 0 deletions
diff --git a/include/uapi/asm-generic/statfs.h b/include/uapi/asm-generic/statfs.h
new file mode 100644
index 000000000..bd35c7619
--- /dev/null
+++ b/include/uapi/asm-generic/statfs.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_GENERIC_STATFS_H
+#define _UAPI_GENERIC_STATFS_H
+
+#include <linux/types.h>
+
+
+/*
+ * Most 64-bit platforms use 'long', while most 32-bit platforms use '__u32'.
+ * Yes, they differ in signedness as well as size.
+ * Special cases can override it for themselves -- except for S390x, which
+ * is just a little too special for us. And MIPS, which I'm not touching
+ * with a 10' pole.
+ */
+#ifndef __statfs_word
+#if __BITS_PER_LONG == 64
+#define __statfs_word __kernel_long_t
+#else
+#define __statfs_word __u32
+#endif
+#endif
+
+struct statfs {
+ __statfs_word f_type;
+ __statfs_word f_bsize;
+ __statfs_word f_blocks;
+ __statfs_word f_bfree;
+ __statfs_word f_bavail;
+ __statfs_word f_files;
+ __statfs_word f_ffree;
+ __kernel_fsid_t f_fsid;
+ __statfs_word f_namelen;
+ __statfs_word f_frsize;
+ __statfs_word f_flags;
+ __statfs_word f_spare[4];
+};
+
+/*
+ * ARM needs to avoid the 32-bit padding at the end, for consistency
+ * between EABI and OABI
+ */
+#ifndef ARCH_PACK_STATFS64
+#define ARCH_PACK_STATFS64
+#endif
+
+struct statfs64 {
+ __statfs_word f_type;
+ __statfs_word f_bsize;
+ __u64 f_blocks;
+ __u64 f_bfree;
+ __u64 f_bavail;
+ __u64 f_files;
+ __u64 f_ffree;
+ __kernel_fsid_t f_fsid;
+ __statfs_word f_namelen;
+ __statfs_word f_frsize;
+ __statfs_word f_flags;
+ __statfs_word f_spare[4];
+} ARCH_PACK_STATFS64;
+
+/*
+ * IA64 and x86_64 need to avoid the 32-bit padding at the end,
+ * to be compatible with the i386 ABI
+ */
+#ifndef ARCH_PACK_COMPAT_STATFS64
+#define ARCH_PACK_COMPAT_STATFS64
+#endif
+
+struct compat_statfs64 {
+ __u32 f_type;
+ __u32 f_bsize;
+ __u64 f_blocks;
+ __u64 f_bfree;
+ __u64 f_bavail;
+ __u64 f_files;
+ __u64 f_ffree;
+ __kernel_fsid_t f_fsid;
+ __u32 f_namelen;
+ __u32 f_frsize;
+ __u32 f_flags;
+ __u32 f_spare[4];
+} ARCH_PACK_COMPAT_STATFS64;
+
+#endif /* _UAPI_GENERIC_STATFS_H */