Curiosities of Linux NFSD file handles

Curiosities of Linux NFSD file handles

[David Howells]

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.

Is this still true?  Or can I assume that the amount of data now given to the
decoder will exactly reflect the amount of data obtained from the encoder?

David

Re: Curiosities of Linux NFSD file handles

[J. Bruce Fields]

On Thu, Dec 04, 2008 at 04:46:57PM +0000, David Howells 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?

--b.

> Is this still true?  Or can I assume that the amount of data now given to the
> decoder will exactly reflect the amount of data obtained from the encoder?

Re: Curiosities of Linux NFSD file handles

[NeilBrown]

On Fri, December 5, 2008 6:35 am, J. Bruce Fields wrote:
> On Thu, Dec 04, 2008 at 04:46:57PM +0000, David Howells 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?
>

I'm with Bruce here - what exactly do you mean?

The decode routine cannot assume anything about the filehandle
as it was received from the network and so is inherently untrustworthy.
However if it finds anything that it did not expect (i.e. that
encode could not have generated) then it is free to return an error.

NeilBrown

Re: Curiosities of Linux NFSD file handles

[David Howells]

J. Bruce Fields <bfields@fieldses.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

Re: Curiosities of Linux NFSD file handles

[David Howells]

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