Re: [PATCH 06/13] cifs: add new cifs_iget function and convert unix codepath to use it

On Mon, May 11, 2009 at 04:24:25PM -0400, Jeff Layton wrote:
> Add a new cifs_iget function that uses iget5_locked to identify inodes.
> This will compare inodes based on the uniqueid value in a cifs_fattr
> struct.
> 
> Rather than filling out an already-created inode, have
> cifs_get_inode_info_unix instead fill out cifs_fattr and hand that off
> to cifs_iget. cifs_iget can then properly look for hardlinked inodes.
> 
> With this, we should then have proper hardlink detection and can
> eventually get rid of some nasty CIFS-specific hacks for handing them.
> 
> Fixing the unix readdir codepath will be done in a later patch.
> 
> Signed-off-by: Jeff Layton <[email protected]>

> +	fattr = cifs_unix_basic_to_fattr(presp_data, cifs_sb);
> +	if (!fattr) {
> +		rc = -ENOMEM;
> +		goto posix_open_ret;
> +	}

The cifs_fattr is probably small enough to be stored on-stack in
many places.  And a calling convention where allocations if needed
are done by the caller and cifs_unix_basic_to_fattr just fills the
buffer is probably nicer either way.

>  /*
> + * Allocate a cifs_fattr struct and fill it with fake inode info.
> + *
> + * Needed to setup cifs_fattr data for the directory which is the
> + * junction to the new submount (ie to setup the fake directory
> + * which represents a DFS referral).
> + *
> + * Returns pointer to new cifs_fattr or NULL on error.
>   */

> +static struct cifs_fattr *
> +cifs_create_fake_fattr(struct super_block *sb)

Same comment about caling conventions applies here, too.

Also wou;dn't something like cifs_create_dfsmount_fattr be a better
name?

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html