From: Heiko Carstens <hca@linux.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Amir Goldstein <amir73il@gmail.com>,
Chris Down <chris@chrisdown.name>,
Hugh Dickins <hughd@google.com>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Linux-MM <linux-mm@kvack.org>, Matt Turner <mattst88@gmail.com>,
mm-commits@vger.kernel.org, Richard Henderson <rth@twiddle.net>,
Seth Forshee <seth.forshee@canonical.com>,
stable <stable@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
Tuan Hoang1 <Tuan.Hoang1@ibm.com>
Subject: Re: [patch 09/14] tmpfs: disallow CONFIG_TMPFS_INODE64 on alpha
Date: Wed, 10 Feb 2021 14:34:05 +0100 [thread overview]
Message-ID: <YCPgzb1PhtvfUh9y@osiris> (raw)
In-Reply-To: <CAHk-=wiDt_eJvfrr-dCXq3eZ+ZmVTD2-rM2pcxBk4d-FM3h-bw@mail.gmail.com>
On Tue, Feb 09, 2021 at 02:03:19PM -0800, Linus Torvalds wrote:
> On Tue, Feb 9, 2021 at 1:42 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > As with s390, alpha is a 64-bit architecture with a 32-bit ino_t. With
> > CONFIG_TMPFS_INODE64=y tmpfs mounts will get 64-bit inode numbers and
> > display "inode64" in the mount options, whereas passing "inode64" in the
> > mount options will fail.
>
> Ugh.
>
> The two patches for s390 and alpha are obviously the right thing to
> do, but I do wonder if we could strive to make __kernel_ino_t go away
> entirely.
>
> It's actually not used very much, because it's such a nasty type, and
> s390 and alpha are the only ones that override it from the default
> "word length" version (and honestly, even that default is not a great
> type).
>
> The main use of it is for "ino_t" and for "struct ustat".
>
> And yes, "ino_t" is widely used, but I think pretty much all uses of
> it are entirely internal to the kernel, and we could just make it be
> "unsigned long".
>
> Does anybody see any actual user interfaces that depend on
> "__kernel_ino_t", aka "ino_t" (apart from that "struct ustat")?
>
> I guess this is mostly a question for s390, which is actively maintained?
I couldn't spot any and also gave the patch below a try and my system
still boots without any errors.
So, as far as I can tell it _should_ be ok to change this.
Note that the unusual 32 bit ino_t also recently caused a bug on
s390. See commit ebce3eb2f7ef ("ceph: fix inode number handling on
arches with 32-bit ino_t"). So getting rid of this would be a good
thing.
diff --git a/arch/Kconfig b/arch/Kconfig
index 24862d15f3a3..383c98e86a70 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -327,6 +327,10 @@ config ARCH_32BIT_OFF_T
still support 32-bit off_t. This option is enabled for all such
architectures explicitly.
+# Selected by 64 bit architectures which have a 32 bit f_tinode in struct ustat
+config ARCH_32BIT_USTAT_F_TINODE
+ bool
+
config HAVE_ASM_MODVERSIONS
bool
help
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 1f51437d5765..96ce6565890e 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -2,6 +2,7 @@
config ALPHA
bool
default y
+ select ARCH_32BIT_USTAT_F_TINODE
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select ARCH_NO_PREEMPT
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c72874f09741..434efd9ca0c5 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -58,6 +58,7 @@ config S390
# Note: keep this list sorted alphabetically
#
imply IMA_SECURE_AND_OR_TRUSTED_BOOT
+ select ARCH_32BIT_USTAT_F_TINODE
select ARCH_BINFMT_ELF_STATE
select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEBUG_WX
diff --git a/fs/statfs.c b/fs/statfs.c
index 68cb07788750..0ba34c135593 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -255,7 +255,10 @@ SYSCALL_DEFINE2(ustat, unsigned, dev, struct ustat __user *, ubuf)
memset(&tmp,0,sizeof(struct ustat));
tmp.f_tfree = sbuf.f_bfree;
- tmp.f_tinode = sbuf.f_ffree;
+ if (IS_ENABLED(CONFIG_ARCH_32BIT_USTAT_F_TINODE))
+ tmp.f_tinode = min_t(u64, sbuf.f_ffree, UINT_MAX);
+ else
+ tmp.f_tinode = sbuf.f_ffree;
return copy_to_user(ubuf, &tmp, sizeof(struct ustat)) ? -EFAULT : 0;
}
diff --git a/include/linux/types.h b/include/linux/types.h
index a147977602b5..1e9d0a2c1dba 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -14,7 +14,7 @@ typedef u32 __kernel_dev_t;
typedef __kernel_fd_set fd_set;
typedef __kernel_dev_t dev_t;
-typedef __kernel_ino_t ino_t;
+typedef __kernel_ulong_t ino_t;
typedef __kernel_mode_t mode_t;
typedef unsigned short umode_t;
typedef u32 nlink_t;
@@ -189,7 +189,11 @@ struct hlist_node {
struct ustat {
__kernel_daddr_t f_tfree;
- __kernel_ino_t f_tinode;
+#ifdef ARCH_HAS_32BIT_F_TINODE
+ unsigned int f_tinode;
+#else
+ unsigned long f_tinode;
+#endif
char f_fname[6];
char f_fpack[6];
};
next prev parent reply other threads:[~2021-02-10 13:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210209134115.4d933d446165cd0ed8977b03@linux-foundation.org>
2021-02-09 21:41 ` [patch 01/14] squashfs: avoid out of bounds writes in decompressors Andrew Morton
2021-02-09 21:41 ` [patch 02/14] squashfs: add more sanity checks in id lookup Andrew Morton
2021-02-09 21:41 ` [patch 03/14] squashfs: add more sanity checks in inode lookup Andrew Morton
2021-02-09 21:42 ` [patch 04/14] squashfs: add more sanity checks in xattr id lookup Andrew Morton
2021-02-09 21:42 ` [patch 08/14] tmpfs: disallow CONFIG_TMPFS_INODE64 on s390 Andrew Morton
2021-02-09 21:42 ` [patch 09/14] tmpfs: disallow CONFIG_TMPFS_INODE64 on alpha Andrew Morton
2021-02-09 22:03 ` Linus Torvalds
2021-02-10 13:34 ` Heiko Carstens [this message]
2021-02-10 17:27 ` Heiko Carstens
2021-02-10 19:17 ` Linus Torvalds
2021-02-10 19:55 ` Arnd Bergmann
2021-02-11 18:45 ` Heiko Carstens
2021-02-09 21:42 ` [patch 12/14] Revert "mm: memcontrol: avoid workload stalls when lowering memory.high" Andrew Morton
2021-02-09 21:42 ` [patch 13/14] mm, slub: better heuristic for number of cpus when calculating slab order Andrew Morton
2021-02-10 14:34 ` Vlastimil Babka
2021-02-10 19:22 ` Linus Torvalds
2021-02-09 21:42 ` [patch 14/14] nilfs2: make splice write available again Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YCPgzb1PhtvfUh9y@osiris \
--to=hca@linux.ibm.com \
--cc=Tuan.Hoang1@ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=borntraeger@de.ibm.com \
--cc=chris@chrisdown.name \
--cc=gor@linux.ibm.com \
--cc=hughd@google.com \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-mm@kvack.org \
--cc=mattst88@gmail.com \
--cc=mm-commits@vger.kernel.org \
--cc=rth@twiddle.net \
--cc=seth.forshee@canonical.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).