J. Bruce Fields <bfields@xxxxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
