From mboxrd@z Thu Jan  1 00:00:00 1970
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH] cifs: Allow nfsd over cifs
Date: Mon, 28 Feb 2011 18:42:26 -0500
Message-ID: <20110228234225.GC14237@fieldses.org>
References: <1298929961-5541-1-git-send-email-shirishpargaonkar@gmail.com>
 <20110228224957.GB14237@fieldses.org>
 <AANLkTimDd-m388VJTC1zJtf3Q7LkFcsvNuwcY6vRwt7K@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Return-path: <linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Content-Disposition: inline
In-Reply-To: <AANLkTimDd-m388VJTC1zJtf3Q7LkFcsvNuwcY6vRwt7K-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
List-ID: <linux-cifs.vger.kernel.org>

On Mon, Feb 28, 2011 at 04:58:57PM -0600, Steve French wrote:
> On Mon, Feb 28, 2011 at 4:49 PM, J. Bruce Fields <bfields-uC3wQj2KruMpug/h7KTFAQ@public.gmane.org=
g> wrote:
> > On Mon, Feb 28, 2011 at 03:52:41PM -0600, shirishpargaonkar@gmail.c=
om wrote:
> >> +static struct dentry *
> >> +cifs_fh_to_dentry(struct super_block *sb, struct fid *fh,
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 int fh_len, int fh_type)
> >> +{
> >> + =C2=A0 =C2=A0 struct cifs_fid *cfid =3D (struct cifs_fid *)fh;
> >> + =C2=A0 =C2=A0 struct inode *inode =3D NULL;
> >> + =C2=A0 =C2=A0 struct cifs_fattr fattr;
> >> +
> >>
> >> -#endif /* CIFS_NFSD_EXPORT */
> >> + =C2=A0 =C2=A0 if (fh_type !=3D FILEID_INO32_GEN && fh_type !=3D =
=46ILEID_INO32_GEN_PARENT) {
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cERROR(1, "%s: Can't h=
andle fh type: %d", __func__, fh_type);
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return ERR_PTR(-EINVAL=
);
> >> + =C2=A0 =C2=A0 }
> >>
> >> + =C2=A0 =C2=A0 if (!cfid->cino)
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return ERR_PTR(-ESTALE=
);
> >> +
> >> + =C2=A0 =C2=A0 fattr.cf_uniqueid =3D cfid->cino;
> >> + =C2=A0 =C2=A0 inode =3D iget5_locked(sb, cfid->cino, cifs_find_i=
node_id,
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cifs_init_i=
node, &fattr);
> >> + =C2=A0 =C2=A0 if (IS_ERR(inode))
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return ERR_CAST(inode)=
;
> >> +
> >> + =C2=A0 =C2=A0 return d_obtain_alias(inode);
> >
> > Does the cifs protocol give the client a way to look up a file by i=
node
> > number (or filehandle or equivalent?).
>=20
> There is a unique identifier similar to inode number returned by
> various info calls,
> but cifs calls use either a file handle (returned by an open) or path=
 name to
> look up metadata on a file.
>=20
> Not sure whether the unique identifier can be passed in as input to a=
n
> ioctl useful here.

OK.  Then as things stand we're stuck returning ESTALE to the client
unless we happen to have the inode they're looking for in our cache?

--b.