Re: [linux-cifs-client] [PATCH 2/3] cifs: add new cifs_iget_unix_basic function

[Jeff Layton <jlayton@redhat.com>]

On Wed, 8 Apr 2009 13:05:31 -0400
Christoph Hellwig <hch@infradead.org> wrote:

> On Sun, Apr 05, 2009 at 09:09:20AM -0400, Jeff Layton wrote:
> > Add a new cifs_iget_unix function that uses iget5_locked to identify
> > inodes. This will compare inodes based on the UniqueId value that
> > the server provides when unix extensions are enabled. We also have
> > mounts with unix extensions use that value in the i_ino field (after
> > hashing it down to 32-bits on a 32-bit arches).
> 
> Note that i_ino and ino_t aren't actually all that important.  You
> already do the iget comparisms based on the internal uniqueid, so the
> only thing i_ino is used for is filling out the inode value in
> generic_fattr.  I would suggest to fill it out explicitly in
> cifs_getattr so that you can actually return a 64bit ino there which
> is supported by stat64, possibly under and inode64 mount option.
> 

Thanks, Christoph. That sounds reasonable. I'll do that with the next
iteration.

> > diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
> > index d958044..be639ee 100644
> > --- a/fs/cifs/dir.c
> > +++ b/fs/cifs/dir.c
> > @@ -187,18 +187,16 @@ int cifs_posix_open(char *full_path, struct inode **pinode,
> >  	if (!pinode)
> >  		goto posix_open_ret; /* caller does not need info */
> >  
> > -	if (*pinode == NULL) {
> > -		__u64 unique_id = le64_to_cpu(presp_data->UniqueId);
> > -		*pinode = cifs_new_inode(sb, &unique_id);
> > -	}
> > +	if (*pinode == NULL)
> > +		*pinode = cifs_iget_unix_basic(sb, presp_data);
> >  	/* else an inode was passed in. Update its info, don't create one */
> 
> Not directly related to this patch, but cifs_posix_open really needs
> some restructuring.  The code up to the !pinode check should be the
> basic underlying helper, and the call to cifs_iget_unix_basic and
> posix_fill_in_inode should be moved to those callers that acutally need
> it.
> 

Agreed, and that's not the only place. The current interfaces for this
stuff seem very ad-hoc. A primary goal that have with this patchset is
to not break anything and to keep the changes to a minimum, but I'd
like to see these cleaned up too.

-- 
Jeff Layton <jlayton@redhat.com>