NetBSD Problem Report #1722

From gnats  Fri Nov  3 04:48:47 1995
Received: from amiga2.oscs.montana.edu by pain.lcs.mit.edu (8.6.9/8.6.9) with ESMTP id EAA18732 for <gnats-bugs@gnats.netbsd.org>; Fri, 3 Nov 1995 04:34:47 -0500
Message-Id: <199511030934.CAA13460@amiga2.oscs.montana.edu>
Date: Fri, 3 Nov 1995 02:34:43 -0700
From: osymh@gemini.oscs.montana.edu
Reply-To: osymh@gemini.oscs.montana.edu
To: gnats-bugs@gnats.netbsd.org
Subject: NFS mount on local filesystem may panic
X-Send-Pr-Version: 3.2

>Number:         1722
>Category:       kern
>Synopsis:       Mounting an NFS filesystem over a local filesystem can panic
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 03 04:50:01 +0000 1995
>Closed-Date:    
>Last-Modified:  Mon Feb 28 14:55:32 +0000 2011
>Originator:     Michael L. Hitch
>Release:        19951027
>Organization:
	Information Technology Center
	Montana State University
>Environment:

System: NetBSD amiga2.oscs.montana.edu 1.1_ALPHA NetBSD 1.1_ALPHA (ZEUS) #951027-0: Fri Oct 27 21:08:32 MDT 1995 root@amiga2.oscs.montana.edu:/opt/tmp/src/sys/arch/amiga/compile/ZEUS amiga


>Description:
	If an NFS filesystem is mounted on the same mount point that a
	local filesystem is mounted on, the system may crash.  What
	appears to be happening is that mountd is doing a "delete export"
	on all currently mounted filesystems prior to processing all
	the exported filesystem entries.  When an NFS filesystem
	is mounted on the same directory as a local filesystem, the
	mount() syscall from mountd uses the filesystem type from the
	getmntinfo() call.  The filesystem type for the local filesystem
	could be ufs, so the mount() arguments are initialized using
	the ufs_args structure.  The kernel determines the *_mount()
	routine to call by looking up the path in the mounted filesystem.
	Because the NFS filesystem was mounted last, the kernel will
	call nfs_mount() with incorrect arguments.  In the specific
	crash I have been seeing, the arguments passed from mountd
	contained garbage that cause nfs_mount() to attempt using some
	uninitialized structures in the mount data (specifically, a timer
	queue which had never been set up) and promptly crashed.
>How-To-Repeat:
	Mount a local filesystem (i.e. /dev/sd1g on /mnt), then mount a
	remove file system on the same directory (i.e. remote:/xyz /mnt).
	If the correct (incorrect?) garbage is present, the system will
	crash.
>Fix:
	I don't know what the proper fix would be.  I was able to work
	around the problem by zeroing out the mount argument list in
	mountd.  That resulted in the nfs_args flags being cleared so
	that nfs_mount() wouldn't execute what it had been doing previously.

*** /usr/src/sbin/mountd/mountd.c	Wed Nov  1 05:26:35 1995
--- mountd.c	Sun Oct 29 11:32:49 1995
***************
*** 649,658 ****
  		} targs;

  		if (!strncmp(fsp->f_fstypename, MOUNT_MFS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_FFS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_MSDOS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_ADOSFS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_CD9660, MFSNAMELEN)) {
  			targs.ua.fspec = NULL;
  			targs.ua.export.ex_flags = MNT_DELEXPORT;
  			if (mount(fsp->f_fstypename, fsp->f_mntonname,
--- 649,659 ----
  		} targs;

  		if (!strncmp(fsp->f_fstypename, MOUNT_MFS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_FFS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_MSDOS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_ADOSFS, MFSNAMELEN) ||
  		    !strncmp(fsp->f_fstypename, MOUNT_CD9660, MFSNAMELEN)) {
+ 		    	bzero((char *)&targs, sizeof(targs));
  			targs.ua.fspec = NULL;
  			targs.ua.export.ex_flags = MNT_DELEXPORT;
  			if (mount(fsp->f_fstypename, fsp->f_mntonname,


	Part of the problem is the difference in the nfs_args structure
	and the other *_args structure (ufs_args, etc).  Most *_args
	have common arguements (the fspec pointer, and the export_args
	structure which include a flags entry).  Mountd and the kernel
	get confused about the mount() arguements because mountd thinks
	the path is for a local filesystem, but the kernel name lookup
	returns the last mounted filesystem, which would be the NFS
	filesystem.
>Release-Note:
>Audit-Trail:

From: Wolfgang Solfrank <ws@tools.de>
To: gnats-bugs@gnats.netbsd.org, osymh@gemini.oscs.montana.edu
Cc:  Subject: Re:  kern/1722: NFS mount on local filesystem may crash
Date: Fri, 3 Nov 1995 17:37:35 +0100

 > 	When an NFS filesystem
 > 	is mounted on the same directory as a local filesystem, the
 > 	mount() syscall from mountd uses the filesystem type from the
 > 	getmntinfo() call.  The filesystem type for the local filesystem
 > 	could be ufs, so the mount() arguments are initialized using
 > 	the ufs_args structure.

 The real problem is that mountd only really knows about ufs. The current
 kernel works around this (in part) by making the ufs args part of any other
 mount arguments (except nfs). (Part of) the fix is to separate mounting for
 export from filesystem specific things. For the record, it once was
 separated in pre-4.4 times, but this got lost during the transition to
 4.4BSD. I'll try to dig this up.

 Another problem is that mountd shouldn't try to unexport the filesystems
 in the first place. It results in pretty unobvious behaviour, as you could
 fall into the window of unexported filesystems when trying to mount something
 from a remote host. In this special case it's even worse, as the unexport
 mount addresses a completely different filesystem than expected.

 The real problem probably is that the export list is specified in terms
 of exported directories. It is quite inflexible to have these in an (only
 root writable) file. It would be better to have exporting as option
 on the mount command, and mountd only serving remote mount requests, but
 not fiddling with mount options itself.
 --
 ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800
State-Changed-From-To: open->analyzed 
State-Changed-By: thorpej 
State-Changed-When: Wed Nov 15 20:36:40 PST 1995 
State-Changed-Why:  
Applied the patch, but as noted in the PR, this might not be the most 
correct fix.  Hence the PR remains open. 
Responsible-Changed-From-To: kern-bug-people->fvdl 
Responsible-Changed-By: lukem 
Responsible-Changed-When: Mon Jun 25 14:05:43 PDT 2001 
Responsible-Changed-Why:  
Frank is our NFS guru 
Responsible-Changed-From-To: fvdl->kern-bug-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Mon, 28 Feb 2011 14:55:32 +0000
Responsible-Changed-Why:
Reset responsible field for retired developer.


>Unformatted:

Home	PR Database Search