From: Chris Down <chris@chrisdown.name>
To: linux-fsdevel@vger.kernel.org
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Amir Goldstein <amir73il@gmail.com>,
Jeff Layton <jlayton@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 2/3] fs: inode: Add API to retrieve global next ino using full ino_t width
Date: Fri, 27 Dec 2019 14:30:29 +0000 [thread overview]
Message-ID: <28599683653d3fa779442a24b3b643bc395d88d0.1577456898.git.chris@chrisdown.name> (raw)
In-Reply-To: <cover.1577456898.git.chris@chrisdown.name>
We can't just wholesale replace get_next_ino to use ino_t and 64-bit
atomics because of a few setbacks:
1. This may break some 32-bit userspace applications on a 64-bit kernel
which cannot handle a 64-bit ino_t -- see the comment above
get_next_ino;
2. Some applications inside the kernel already make use of the ino_t
high bits. For example, overlayfs' xino feature uses these to merge
inode numbers and fsid indexes to form a new identifier.
As such we need to make using the full width of ino_t an option for
users without being a requirement.
This will later be used to power inode64 in tmpfs, and can be used
elsewhere for other filesystems as desired.
Signed-off-by: Chris Down <chris@chrisdown.name>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Amir Goldstein <amir73il@gmail.com>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: kernel-team@fb.com
---
fs/inode.c | 41 +++++++++++++++++++++++++++++++++++++----
include/linux/fs.h | 1 +
2 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 255a4ae81b65..1d96ad8b71f6 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -878,16 +878,17 @@ static struct inode *find_inode_fast(struct super_block *sb,
* here to attempt to avoid that.
*/
#define LAST_INO_BATCH 1024
-static DEFINE_PER_CPU(unsigned int, last_ino);
+static DEFINE_PER_CPU(unsigned int, last_ino_ui);
/*
* As get_next_ino returns a type with a small width (typically 32 bits),
* consider reusing inode numbers in your filesystem if you have a private inode
- * cache in order to reduce the risk of wraparound.
+ * cache in order to reduce the risk of wraparound, or consider providing the
+ * option to use get_next_ino_full instead.
*/
unsigned int get_next_ino(void)
{
- unsigned int *p = &get_cpu_var(last_ino);
+ unsigned int *p = &get_cpu_var(last_ino_ui);
unsigned int res = *p;
#ifdef CONFIG_SMP
@@ -904,11 +905,43 @@ unsigned int get_next_ino(void)
if (unlikely(!res))
res++;
*p = res;
- put_cpu_var(last_ino);
+ put_cpu_var(last_ino_ui);
return res;
}
EXPORT_SYMBOL(get_next_ino);
+static DEFINE_PER_CPU(ino_t, last_ino_full);
+
+ino_t get_next_ino_full(void)
+{
+ ino_t *p = &get_cpu_var(last_ino_full);
+ ino_t res = *p;
+
+#ifdef CONFIG_SMP
+ if (unlikely((res & (LAST_INO_BATCH-1)) == 0)) {
+ static atomic64_t shared_last_ino;
+ u64 next = atomic64_add_return(LAST_INO_BATCH,
+ &shared_last_ino);
+
+ /*
+ * This might get truncated if ino_t is 32-bit, and so be more
+ * susceptible to wrap around than on environments where ino_t
+ * is 64-bit.
+ */
+ res = next - LAST_INO_BATCH;
+ }
+#endif
+
+ res++;
+ /* get_next_ino_full should not provide a 0 inode number */
+ if (unlikely(!res))
+ res++;
+ *p = res;
+ put_cpu_var(last_ino_full);
+ return res;
+}
+EXPORT_SYMBOL(get_next_ino_full);
+
/**
* new_inode_pseudo - obtain an inode
* @sb: superblock
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 190c45039359..c73896d993c1 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3053,6 +3053,7 @@ static inline void lockdep_annotate_inode_mutex_key(struct inode *inode) { };
extern void unlock_new_inode(struct inode *);
extern void discard_new_inode(struct inode *);
extern unsigned int get_next_ino(void);
+extern ino_t get_next_ino_full(void);
extern void evict_inodes(struct super_block *sb);
extern void __iget(struct inode * inode);
--
2.24.1
next prev parent reply other threads:[~2019-12-27 14:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-27 14:30 [PATCH 0/3] fs: inode: shmem: Reduce risk of inum overflow Chris Down
2019-12-27 14:30 ` [PATCH 1/3] fs: inode: Recycle volatile inode numbers from private slabs Chris Down
2019-12-27 14:30 ` Chris Down [this message]
2019-12-27 15:32 ` [PATCH 2/3] fs: inode: Add API to retrieve global next ino using full ino_t width Amir Goldstein
2019-12-27 14:30 ` [PATCH 3/3] shmem: Add support for using full width of ino_t Chris Down
2019-12-27 15:26 ` Amir Goldstein
2019-12-27 16:35 ` Chris Down
2019-12-28 4:20 ` Amir Goldstein
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=28599683653d3fa779442a24b3b643bc395d88d0.1577456898.git.chris@chrisdown.name \
--to=chris@chrisdown.name \
--cc=amir73il@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=jlayton@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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).