Date: Mon, 2 Aug 1999 13:40:49 -0400 (EDT) From: Alfred Perlstein <bright@rush.net> To: Peter Wemm <peter@netplex.com.au> Cc: Matthew Dillon <dillon@apollo.backplane.com>, hackers@FreeBSD.ORG Subject: Re: confusion about nfsm_srvmtofh bad behavior? Message-ID: <Pine.BSF.3.96.990802133500.20420o-100000@cygnus.rush.net> In-Reply-To: <19990802173102.CCA101C9F@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990802133500.20420o-100000>