Re: Curiosities of Linux NFSD file handles

[David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:

> > I've been poking around in the exportfs code, and I see that the handle
> > decode routines seem to expect that they may be given more data for a
> > handle than the encode_fh() routine produced.
> 
> Somebody else who understands what you're asking about off the top of
> their heads may be able to pop up and answer this.  But I'm a little
> confused.  Which encode/decode routines exactly, and where do you see
> them making assumptions about the size of the data?

The encode_fh() operation produces a blob of data and passes back the type and
length of this data.

The fh_to_dentry() and fh_to_parent() routines are given back the blob of
data, the handle type and a length, where the length, it would appear, may be
longer than that passed back by encode_fh().  To quote from the Exporting
document:

	The decode_fh routine should not depend on the stated size that is
	passed to it.  This size may be larger than the original filehandle
	generated by encode_fh, in which case it will have been padded with
	nuls.  Rather, the encode_fh routine should choose a "type" which
	indicates the decode_fh how much of the filehandle is valid, and how

Is this still true?

If it isn't true, then there's no need for separate FILEID_INO32_GEN and
FILEID_INO32_GEN_PARENT types.  If it is true, then FILEID_INO32_GEN_PARENT
and the generic routines that handle it are perhaps dodgy as they assume they
can simply set i_generation to 0 if the file handle is short.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html