Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir

[David Howells <dhowells@redhat.com>]

Michael Halcrow <mhalcrow@us.ibm.com> wrote:

> Note that I used to depend on iget() to wind up calling
> ecryptfs_read_inode(); it looks like iget5_locked() does not make that
> call,

Exactly so.  iget5_locked() returns with a new inode in a partially
constructed state, thus obviating the need for read_inode().  If you look at
the implementation of iget():

	static inline struct inode *iget(struct super_block *sb,
					 unsigned long ino)
	{
		struct inode *inode = iget_locked(sb, ino);

		if (inode && (inode->i_state & I_NEW)) {
			sb->s_op->read_inode(inode);
			unlock_new_inode(inode);
		}

		return inode;
	}

You can see that read_inode() is _only_ used there and can be dispensed with
if you're using iget_locked() or iget5_locked() directly.  This gives you more
control over what data you have available when initialising an inode.

> +	inode = iget5_locked(sb, lower_inode->i_ino, ecryptfs_inode_test,
> +			     ecryptfs_inode_set, lower_inode);

The second argument of iget5_locked() is a hash value.  I would use
lower_inode not lower_inode->i_ino as the former is fundamental to your search
and the latter irrelevant.

> +	inode->i_ino = lower_inode->i_ino;
> +	if (inode->i_state & I_NEW) {
> +		ecryptfs_init_inode(inode);
> +		unlock_new_inode(inode);
> +	}

Shouldn't the setting of i_ino be inside the if-statement?

You should set the lower inode pointer in ecryptfs_inode_set() so that the
ecryptfs inode is linked to the lower inode whilst inode_lock is held (see
get_new_inode()).  You could also set i_ino there too.  Consider this bit of
pseudocode:

	int ecryptfs_inode_set(struct inode *inode, void *lower_inode)
	{
		ecryptfs_set_lower_inode(inode, lower_inode);
		inode->i_ino = lower_inode->i_ino;
		return 0;
	}

David
-
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/