From owner-freebsd-current  Mon Jun 14 20: 1: 7 1999
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP id 363E614E4B
	for <freebsd-current@FreeBSD.ORG>; Mon, 14 Jun 1999 20:01:05 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id UAA13883;
	Mon, 14 Jun 1999 20:00:59 -0700 (PDT)
	(envelope-from dillon)
Date: Mon, 14 Jun 1999 20:00:59 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199906150300.UAA13883@apollo.backplane.com>
To: "David E. Cross" <crossd@cs.rpi.edu>
Cc: Chuck Robey <chuckr@picnic.mat.net>,
	David Scheidt <dscheidt@enteract.com>,
	Chan Yiu Wah <c5666305@hkstar.com>, freebsd-current@FreeBSD.ORG,
	crossd@cs.rpi.edu
Subject: Re: What happened to CTM src-cur? 
References:  <199906150028.UAA22149@cs.rpi.edu>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:Yes, that was far from my final patch :) It was intended for those with more
:clue, and a fresh look at the code (such as yourself ;) to help me out.  
:I don't believe that we have handled all the problems, I believe almost 
:any "error" condition may cause this... there are multiple points at which
:"error=" occurs, and it would seem to suggest that any may lead to this.  I
:have a giant printout of this routine and I am atytempting to trace all the 
:code paths.  

    Hmm.. yes, you are right, it looks like there is another case
    around line 1440 of nfs_serv.c.

                        if (!error) {
                                nfsrv_object_create(nd.ni_vp);
                                zfree(namei_zone, nd.ni_cnd.cn_pnbuf);
                                if (exclusive_flag) {
                                        exclusive_flag = 0;
                                        VATTR_NULL(vap);
                                        bcopy(cverf, (caddr_t)&vap->va_atime,
                                                NFSX_V3CREATEVERF);
      >>>>>>>>>                         error = VOP_SETATTR(nd.ni_vp, vap, cred,
                                                procp);
                                }
                        }

    There is a possible case in handling the VOP_MKNOD call at line 
    1459.  The section of code at line 1469 sets error but does not
    dispose of the vp anywhere later on:

                        if ((error = lookup(&nd)) != 0) {
                                zfree(namei_zone, nd.ni_cnd.cn_pnbuf);
                                nfsm_reply(0);
                        }

    Those are the only other two cases I can see.  The other places
    where error is returned should leave nd.ni_vp NULL.

    The easiest solution is to track the vp and NULL it out whenever
    it gets vput, then put an KASSERT where the code returns to make
    sure vp is NULL.

:Could someone provide an indication as to what (paraphrasing) "vattr->va_size
:=-1" would parse to in english?

    I don't know.  Yet :-)

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:--
:David Cross
:The source will be with you, always.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message