From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: Curiosities of Linux NFSD file handles Date: Fri, 05 Dec 2008 09:07:00 +0000 Message-ID: <25993.1228468020@redhat.com> References: <20081204193511.GE7575@fieldses.org> <19603.1228409217@redhat.com> Cc: dhowells@redhat.com, Neil Brown , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org To: "J. Bruce Fields" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:34180 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922AbYLEJHK (ORCPT ); Fri, 5 Dec 2008 04:07:10 -0500 In-Reply-To: <20081204193511.GE7575@fieldses.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: J. Bruce Fields 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