From owner-cvs-sys  Fri Jun 27 14:01:00 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id OAA15117
          for cvs-sys-outgoing; Fri, 27 Jun 1997 14:01:00 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15110;
          Fri, 27 Jun 1997 14:00:56 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id GAA05782; Sat, 28 Jun 1997 06:55:49 +1000
Date: Sat, 28 Jun 1997 06:55:49 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199706272055.GAA05782@godzilla.zeta.org.au>
To: bde@zeta.org.au, wpaul@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/nfs nfs_vfsops.c
Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>I was wondering how a change to nfsrv_mknod() was supposed to fix this
>since I never call mknod() on the filesystem.

You mentioned a label `nfsmout' and it was near my fix so I assumed that
my fix was in a general function.  Actually `nfsmout' is used a lot and
bugs near it are probably duplicated :(.

>That said, nfsrv_statfs() in the nfs_serv.c module also does things
>like:
>
>        if (v3)
>                nfsm_srvpostop_attr(getret, &at);
>        if (error)
>                return (0);
>
>Shouldn't this be:
>
>	if (error)
>		return(error);
>
>Or am I missing something.

The error code seems to be returned indirectly in nfsm_reply(), and
return(0) is common after nfsm_reply().  I guess some cases like the
above break this by changing `error' after invoking nfsm_reply().
Note that there is only a problem here in the v3 case.

Bruce