[comp.sys.dec] NFS bug in Ultrix 3.1

megauter@watcgl.waterloo.edu (Marc E. Gauthier) (11/06/90)

In developing an NFS client implementation, I discovered a bug in NFS server
implementations under Ultrix (Ultrix-32 V3.1 (Rev. 11)).  The VAXen servers
kept crashing while testing my client, and I wondered why - it seems that any
time I refer to a file outside the filesystem I have mounted (either through an
unmounted mount point, or by giving absolute path names), the VAX panics and
reboots.  Although what I was doing was `improper' client behaviour since I
was giving pathnames for the server to parse, it still shouldn't crash the
server...  Anybody come upon this?

Is there a proper DEC contact point for sending such bug reports?
-Marc
-- 
Marc E. Gauthier   megauthier@watcgl.waterloo.edu   University of Waterloo
		   129.97.128.64		    885-1211 x3469 or x4548

alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (11/06/90)

In article <1990Nov6.022044.19498@watcgl.waterloo.edu>, megauter@watcgl.waterloo.edu (Marc E. Gauthier) writes:
> In developing an NFS client implementation, I discovered a bug in NFS server
> implementations under Ultrix (Ultrix-32 V3.1 (Rev. 11)).  The VAXen servers
> kept crashing while testing my client, and I wondered why - it seems that any
> time I refer to a file outside the filesystem I have mounted (either through an
> unmounted mount point, or by giving absolute path names), the VAX panics and
> reboots.  Although what I was doing was `improper' client behaviour since I
> was giving pathnames for the server to parse, it still shouldn't crash the
> server...  Anybody come upon this?

	It sounds vaguely familiar.  It is also probably fixed in
	V4.0, so you should consider installing V4.
> 
> Is there a proper DEC contact point for sending such bug reports?

	Go through your doc set and look for a half-dozen or so
	carbon paper thing.  If it says Software Performance
	Report, then you've found the right one.  If you don't
	find one can get one from your local DEC office.  If you
	have a support contract you might be submit one through
	them without ever having to touch the paper kind.

> -- 
> Marc E. Gauthier   megauthier@watcgl.waterloo.edu   University of Waterloo
> 		   129.97.128.64		    885-1211 x3469 or x4548


-- 
Alan Rollow				alan@nabeth.enet.dec.com

sfreed@gauss.unm.edu (Steve Freed) (11/08/90)

In article <1990Nov6.022044.19498@watcgl.waterloo.edu>, megauter@watcgl.waterloo.edu (Marc E. Gauthier) writes:
> In developing an NFS client implementation, I discovered a bug in NFS server
> implementations under Ultrix (Ultrix-32 V3.1 (Rev. 11)).  The VAXen servers
> kept crashing while testing my client, and I wondered why - it seems that any
> time I refer to a file outside the filesystem I have mounted (either through an
> unmounted mount point, or by giving absolute path names), the VAX panics and
> reboots.

     In /usr/include/fs/nfs/nfs.h, the structure declaration for NFS file
handles (fhandle_t) is incorrect.  This causes sizeof(struct fhandle_t) to
yield 36 instead of the proper size (32).  The Ultrix kernel code that handles
the caching of NFS file handles depends upon this size and because of the
mis-declaration, it breaks when you use it.. this is also true when trying
to use amd.

Workarounds:

     For Ultrix 3.1, change the rfind() routine in sys/fs/nfs/nfs_subr.c to
use the proper file handle size.

*** /tmp/,RCSt1a09412   Wed Oct 24 15:14:09 1990
--- /tmp/,RCSt2a09412   Wed Oct 24 15:14:14 1990
***************
*** 748,754 ****
--- 748,760 ----
        for (gp = ih->gh_chain[0]; gp != (struct gnode *)ih; gp = gp->g_forw) {
                if (gno == gp->g_number && fsid == gp->g_dev) {

+ #ifdef UW
+                       /* For the MIPS architecture, sizeof(*fh) = 36,
+                          instead of the expected 32. */
+                       if (bcmp(vtofh((struct vnode *)gp), fh, NFS_FHSIZE)) {
+ #else
                        if (bcmp(vtofh((struct vnode *)gp), fh, sizeof(*fh))) {
+ #endif UW
  if (cachedebug) printf("rfind: rejected stale gnode, #%d, 0x%x\n",
  gp->g_number, gp);
                                continue;

For Ultrix 4.0, make the equivalent change to the nfs_match() routine in
sys/fs/nfs/nfs_subr.c:

*** /tmp/,RCSt1a09579   Wed Oct 24 15:27:21 1990
--- nfs_subr.c  Wed Oct 24 15:25:25 1990
***************
*** 607,613 ****
--- 607,619 ----
        struct rnode_data *rdp;
  {
        return(!bcmp(vtofh((struct vnode *)gp), rdp->rn_fh,
+ #ifdef UW
+                    /* For the MIPS architecture, sizeof(*fh) = 36,
+                       instead of the expected 32. */
+                    NFS_FHSIZE));
+ #else
                sizeof(fhandle_t)));
+ #endif UW
  }

  /*


-- 

Thanks,
Steve.                    sfreed@ariel.unm.edu

stefan@wheaton.UUCP (Stefan Brandle ) (11/09/90)

In article <1990Nov6.022044.19498@watcgl.waterloo.edu> megauter@watcgl.waterloo.edu (Marc E. Gauthier) writes:
>In developing an NFS client implementation, I discovered a bug in NFS server
...
>unmounted mount point, or by giving absolute path names), the VAX panics and
>reboots.  Although what I was doing was `improper' client behaviour since I
>was giving pathnames for the server to parse, it still shouldn't crash the
>server...  Anybody come upon this?

We are using a GatorBox that allows Macintoshes to access NFS servers and see
the files there as AppleShare volumes.  It's a very nice idea, except that when
doing big multi-file copying we can crash any of our VAXen almost on demand.
I had never gotten anywhere trying to determing what happened; maybe it's
related.  I agree that a client should not be able to crash the server.

-Stefan Brandle
-- 
---------------------------------------------- MA Bell: (708) 260-4110 ---------
Stefan Brandle                  UUCP: ...!{obdient,uunet!tellab5}!wheaton!stefan
Wheaton College			or	stefan@wheaton.UUCP
Wheaton, IL 60187 		"But I never claimed to be sane!"

frank@croton.enet.dec.com (Frank Wortner) (11/12/90)

Just doing a quick check here ...

There have been several patches for NFS-related problems in 3.1.
Have you contacted the CSC (Atlanta) about these?  If not, give it a
shot;  they might have the proper fix for your problem.

					Frank