Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Aug 1999 08:17:14 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Alfred Perlstein <bright@rush.net>, hackers@FreeBSD.ORG
Subject:   Re: confusion about nfsm_srvmtofh bad behavior?
Message-ID:  <199908021517.IAA13341@apollo.backplane.com>
References:  <Pine.BSF.3.96.990802072500.20420l-100000@cygnus.rush.net> <199908021513.IAA13285@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

::> 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 
:					<dillon@backplane.com>

    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 
					<dillon@backplane.com>


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?199908021517.IAA13341>