From owner-freebsd-hackers Mon Aug 2 10:40: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id E6ECF14D54 for ; Mon, 2 Aug 1999 10:39:48 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id NAA22604; Mon, 2 Aug 1999 13:40:51 -0400 (EDT) Date: Mon, 2 Aug 1999 13:40:49 -0400 (EDT) From: Alfred Perlstein To: Peter Wemm Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: confusion about nfsm_srvmtofh bad behavior? In-Reply-To: <19990802173102.CCA101C9F@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 3 Aug 1999, Peter Wemm wrote: > Alfred Perlstein wrote: > > On Mon, 2 Aug 1999, Matthew Dillon wrote: > > > > http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff > > > > This is a patch that Peter Wemm proposed however he had this: > > > > ! if (fhlen < NFSX_V3FH) { \ > > ! bzero((caddr_t)(f) + fhlen, NFSX_V3FH - fhlen); \ > > ! } \ > > > > right before the while(0) instead of the else clause with the > > full bzero. > > > > i'd rather get rid of the extra copying going on and since > > previously it was filled with garbage from the rest of the RPC > > structure i don't think it's nessesary. > > Right now it seems we're generating 8 bytes of fsid and 12 (padded to 16) > bytes of handle data in the common case for a total of 24 bytes of filehandle. > Then we pad that to 32 bytes for V2 or 64 bytes for V3, with random crud. > Then we copy this around, store it all in memory, transmit it over the wire, > etc. It's a nightmare. yes, ick! :) > NFSv2 filehandles are fixed at 32 bytes long. For V3 we could probably just > transmit 24 byte filehandles rather than 64. (I'll reread the spec to make > sure there isn't a v3 minimum size). there isn't, the only reason i can think of forcing it to the full 64 bytes is that it may interact badly with other NFS implementations that may not handle it correctly. > > That explicit zero on the end is probably redundant since we've been using > random data in it's place since day 1. (We do need (I think) the fhlen == > 0 bzero though). It should probably error and do the same thing that happens above, however, i'm too tired to determine if it's safe to do that after the second nfsm_dissect(), and since it's an error condition that would only happen with a corrupted packet or somesuch it can probably be left alone. I appreciate the time you've taken on IRC to enlighten me about these things. thank you, -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message