linux-kernel - Re: [PATCH 4/4] eCryptfs: ino

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10689.1157020231@warthog.cambridge.redhat.com>
Date:	Thu, 31 Aug 2006 11:30:31 +0100
From:	David Howells <dhowells@...hat.com>
To:	Michael Halcrow <mhalcrow@...ibm.com>
Cc:	David Howells <dhowells@...hat.com>, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] eCryptfs: ino_t to u64 for filldir 

Michael Halcrow <mhalcrow@...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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/