From: Jeff Layton <jlayton@redhat.com>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
Date: Fri, 1 Dec 2006 12:21:36 -0500 [thread overview]
Message-ID: <20061201172136.GA11669@dantu.rdu.redhat.com> (raw)
In-Reply-To: <20061201085227.2463b185.randy.dunlap@oracle.com>
On Fri, Dec 01, 2006 at 08:52:27AM -0800, Randy Dunlap wrote:
Thanks for having a look, Randy...
> s/idr_/iunique_/
Doh! Can you tell I cut and pasted this email from earlier ones? :-)
> > - don't attempt to remove inodes with values <100
>
> Please explain that one. (May be obvious to some, but not to me.)
Actually, we probably don't need to do that now. My thought here was to add
a low range of i_ino numbers that could be used by the filesystem code without
needing to call iunique (in particular for things like the root inode in the
filesystem). It's probably best to not do this though and let the filesystem
handle it on its own.
> Better to post patches inline (for review) rather than as attachments.
Here's an updated (but untested) patch based on your suggestions. I also went
ahead and made the exported symbols GPL-only since that seems like it would be
appropriate here. Any further thoughts on it?
Signed-off-by: Jeff Layton <jlayton@redhat.com>
diff --git a/fs/inode.c b/fs/inode.c
index 26cdb11..e45cec9 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -288,6 +288,8 @@ static void dispose_list(struct list_hea
list_del_init(&inode->i_sb_list);
spin_unlock(&inode_lock);
+ iunique_unregister(inode);
+
wake_up_inode(inode);
destroy_inode(inode);
nr_disposed++;
@@ -706,6 +708,32 @@ retry:
EXPORT_SYMBOL(iunique);
+int iunique_register(struct inode *inode, int max_reserved)
+{
+ int rv;
+
+ rv = idr_pre_get(&inode->i_sb->s_inode_ids, GFP_KERNEL);
+ if (! rv)
+ return -ENOMEM;
+
+ spin_lock(&inode->i_sb->s_inode_ids_lock);
+ rv = idr_get_new_above(&inode->i_sb->s_inode_ids, inode,
+ max_reserved+1, (int *) &inode->i_ino);
+ inode->i_generation = inode->i_sb->s_generation++;
+ spin_unlock(&inode->i_sb->s_inode_ids_lock);
+ return rv;
+}
+EXPORT_SYMBOL_GPL(iunique_register);
+
+void iunique_unregister(struct inode *inode)
+{
+ spin_lock(&inode->i_sb->s_inode_ids_lock);
+ if (idr_find(&inode->i_sb->s_inode_ids, (int) inode->i_ino))
+ idr_remove(&inode->i_sb->s_inode_ids, (int) inode->i_ino);
+ spin_unlock(&inode->i_sb->s_inode_ids_lock);
+}
+EXPORT_SYMBOL_GPL(iunique_unregister);
+
struct inode *igrab(struct inode *inode)
{
spin_lock(&inode_lock);
@@ -1025,6 +1053,7 @@ void generic_delete_inode(struct inode *
spin_lock(&inode_lock);
hlist_del_init(&inode->i_hash);
spin_unlock(&inode_lock);
+ iunique_unregister(inode);
wake_up_inode(inode);
BUG_ON(inode->i_state != I_CLEAR);
destroy_inode(inode);
@@ -1057,6 +1086,7 @@ static void generic_forget_inode(struct
inode->i_state |= I_FREEING;
inodes_stat.nr_inodes--;
spin_unlock(&inode_lock);
+ iunique_unregister(inode);
if (inode->i_data.nrpages)
truncate_inode_pages(&inode->i_data, 0);
clear_inode(inode);
diff --git a/fs/pipe.c b/fs/pipe.c
index b1626f2..d74ae65 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -845,6 +845,9 @@ static struct inode * get_pipe_inode(voi
if (!inode)
goto fail_inode;
+ if (iunique_register(inode, 0))
+ goto fail_iput;
+
pipe = alloc_pipe_info(inode);
if (!pipe)
goto fail_iput;
diff --git a/fs/super.c b/fs/super.c
index 47e554c..d2dbdec 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -93,6 +93,8 @@ static struct super_block *alloc_super(s
s->s_qcop = sb_quotactl_ops;
s->s_op = &default_op;
s->s_time_gran = 1000000000;
+ idr_init(&s->s_inode_ids);
+ spin_lock_init(&s->s_inode_ids_lock);
}
out:
return s;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 2fe6e3f..3afb4a2 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -278,6 +278,7 @@ #include <linux/prio_tree.h>
#include <linux/init.h>
#include <linux/sched.h>
#include <linux/mutex.h>
+#include <linux/idr.h>
#include <asm/atomic.h>
#include <asm/semaphore.h>
@@ -961,6 +962,12 @@ #endif
/* Granularity of c/m/atime in ns.
Cannot be worse than a second */
u32 s_time_gran;
+
+ /* for fs's with dynamic i_ino values, track them with idr, and increment
+ the generation every time we register a new inode */
+ __u32 s_generation;
+ struct idr s_inode_ids;
+ spinlock_t s_inode_ids_lock;
};
extern struct timespec current_fs_time(struct super_block *sb);
@@ -1681,6 +1688,8 @@ extern void inode_init_once(struct inode
extern void iput(struct inode *);
extern struct inode * igrab(struct inode *);
extern ino_t iunique(struct super_block *, ino_t);
+extern int iunique_register(struct inode *inode, int max_reserved);
+extern void iunique_unregister(struct inode *inode);
extern int inode_needs_sync(struct inode *inode);
extern void generic_delete_inode(struct inode *inode);
extern void generic_drop_inode(struct inode *inode);
next prev parent reply other threads:[~2006-12-01 17:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-01 14:48 [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr) Jeff Layton
2006-12-01 16:52 ` Randy Dunlap
2006-12-01 17:21 ` Jeff Layton [this message]
2006-12-01 17:42 ` Randy Dunlap
2006-12-02 5:30 ` Brad Boyer
2006-12-03 2:56 ` Jeff Layton
2006-12-02 12:58 ` Brad Boyer
2006-12-03 11:52 ` Al Boldi
2006-12-03 12:49 ` Jeff Layton
-- strict thread matches above, loose matches on Subject: below --
2006-11-14 20:22 Jeff Layton
2006-11-14 20:26 ` Al Viro
2006-11-15 16:42 ` Jeff Layton
2006-11-15 16:44 ` Jeff Layton
2006-11-16 14:06 ` Al Viro
2006-11-16 14:34 ` Jeff Layton
2006-11-15 17:27 ` Matthew Wilcox
2006-11-15 17:56 ` Jörn Engel
2006-11-15 20:36 ` Jeff Layton
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=20061201172136.GA11669@dantu.rdu.redhat.com \
--to=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
/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).