From owner-cvs-sys  Fri Jun 27 12:14:38 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA08908
          for cvs-sys-outgoing; Fri, 27 Jun 1997 12:14:38 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08773;
          Fri, 27 Jun 1997 12:12:11 -0700 (PDT)
From: Bill Paul <wpaul@FreeBSD.ORG>
Received: (from wpaul@localhost)
	by freefall.freebsd.org (8.8.5/8.8.5) id MAA10921;
	Fri, 27 Jun 1997 12:10:47 -0700 (PDT)
Date: Fri, 27 Jun 1997 12:10:47 -0700 (PDT)
Message-Id: <199706271910.MAA10921@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject: cvs commit: src/sys/nfs nfs_vfsops.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

wpaul       1997/06/27 12:10:47 PDT

  Modified files:
    sys/nfs              nfs_vfsops.c 
  Log:
  Fix a condition where nfs_statfs() can precipitate a panic. There is
  code that says this:
  
          nfsm_request(vp, NFSPROC_FSSTAT, p, cred);
          if (v3)
                  nfsm_postop_attr(vp, retattr);
          if (!error)
                  nfsm_dissect(sfp, struct nfs_statfs *, NFSX_STATFS(v3));
  
  The problem here is that if error != 0, nfsm_dissect() will not be
  called, which leaves sfp == NULL. But nfs_statfs() does not bail out
  at this point: it continues processing until it tries to dereference
  sfp, which causes a panic. I was able to generate this crash under
  the following conditions:
  
  1) Set up a machine as an NFS server and NFS client, with amd running
     (using NIS maps). /usr/local is exported, though any exported fs
     can can be used to trigger the bug.
  2) Log in as normal user, with home directory mounted from a SunOS 4.1.3
     NFS server via amd (along with a few other NFS filesystems from same
     machine).
  3) Su to root and type the following:
     # mount localhost:/usr/local /mnt
     # df
  
  To fix the panic, I changed the code to read:
  
          if (!error) {
                  nfsm_dissect(sfp, struct nfs_statfs *, NFSX_STATFS(v3));
          } else
                  goto nfsmout;
  
  This is a bit kludgy in that nfsmout is a label defined by the nfsm_subs.h
  macros, but these macros are themselves more than a little kludgy. This
  stops the machine from crashing, but does not fix the overall bug: 'error'
  somehow becomes 5 (EIO) when a statfs() is performed on the locally mounted
  NFS filesystem. This seems to only happen the first time the filesystem
  is accesed: on subsequent accesses, it seems to work fine again.
  
  Now, I know there's no practical use in mounting a local filesystem
  via NFS, but doing it shouldn't cause the system to melt down.
  
  Revision  Changes    Path
  1.44      +5 -2      src/sys/nfs/nfs_vfsops.c