From owner-freebsd-hackers Mon Aug 2 8:18:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8CD381518B for ; Mon, 2 Aug 1999 08:18:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA13341; Mon, 2 Aug 1999 08:17:14 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Aug 1999 08:17:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199908021517.IAA13341@apollo.backplane.com> To: Matthew Dillon Cc: Alfred Perlstein , hackers@FreeBSD.ORG Subject: Re: confusion about nfsm_srvmtofh bad behavior? References: <199908021513.IAA13285@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ::> it then rewinds the mbuf pointers (i think) because of the ::> over "dissection" above. ::> --- ::> ::> why does it do the copy, then rewind it, it seems like it knows ::> it's doing something wrong and instead of fixing it, it just ::> compensates after the fact. :: ::yes, replying to my own message. :: ::the only thing i can think of is that the extra data is safely ::ignored because the routines that use these macros seem to ::pass the version of NFS to all the function that they call... :: ::however unless i'm wrong (which i probably am) nfsV2 stuff ::could be made faster if it was correctly noted and less data ::was copied. It would also DTRT and not access data it isn't ::supposed to :) :: ::it seems like all of the V3 handles are the same length so ::there isn't much to do there... :: ::-Alfred : : Well, I must say that it certainly looks like a bug. It is not going : to blow anything up since the nfsm_dissect() will break out if it runs : out of buffer space, but it certainly seems inefficient. I am somewhat : loath to fix anything in NFS that does not create a demonstrateable : problem for fear of creating new problems, though, it is quite possible : that the server code depends on the extra junk in the file handle for : V2 mounts - A full audit of nfs_nqlease.c and nfs_serv.c would be : necessary before this could be fixed. : : -Matt : Matthew Dillon : Oh, p.s. But in the mean time, if you or someone would like to commit an XXX comment to document the potential bug / performance problem, I think that would be very appropriate. e.g. /* * Extract file handle from NFS stream. XXX note that the extraction of * the file handle for an NFSv2 mount appears to be rather odd. It is copying * NFSX_V3FH bytes instead of NFSX_V2FH and then rewinding the mbuf index. */ #define nfsm_srvmtofh(f) \ { int fhlen = NFSX_V3FH; \ if (nfsd->nd_flag & ND_NFSV3) { \ nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \ fhlen = fxdr_unsigned(int, *tl); \ ... -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message