Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)

[Randy Dunlap <randy.dunlap@oracle.com>]

Jeff Layton wrote:
> 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?

Just needs new/updated patch description.
and one "typo" fixed.

> diff --git a/fs/inode.c b/fs/inode.c
> index 26cdb11..e45cec9 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -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)

No space after !, just:
	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;
> +}

Thanks.
--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/