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