From nobody@FreeBSD.ORG Mon Apr  5 02:41:04 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id F1C3A153EA; Mon,  5 Apr 1999 02:41:03 -0700 (PDT)
Message-Id: <19990405094103.F1C3A153EA@hub.freebsd.org>
Date: Mon,  5 Apr 1999 02:41:03 -0700 (PDT)
From: ulianov@ns.csm.ro
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: 3.1-STABLE crashes due to a floppy mount problem
X-Send-Pr-Version: www-1.0

>Number:         10959
>Category:       kern
>Synopsis:       3.1-STABLE crashes due to a floppy mount problem
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr  5 02:40:01 PDT 1999
>Closed-Date:    Fri Aug 4 00:50:36 PDT 2000
>Last-Modified:  Fri Aug 04 00:54:18 PDT 2000
>Originator:     Vladimir COTFAS
>Release:        3.1-STABLE
>Organization:
NetAppi
>Environment:
FreeBSD cmell 3.1-RELEASE FreeBSD 3.1-RELEASE #0: Sun Apr  2 20:35:45 EEST 2000     root@cmell:/usr/src/sys/compile/SOUL  i386
>Description:
While trying to (incorrectly) mount a read-only DOS formatted diskette
as a read-write medium encountered NO error (BTW Linux complains and 
mounts it read-only). "Wrote" a file to this filesystem and then dismounted
it. The result was a nice crash.
This strange behaviour is present even in the GENERIC kernel shipped with
the 3.1-STABLE distribution.
>How-To-Repeat:
1. pick a read-only DOS-formated diskette and insert it into the drive
2. mount -t msdos /dev/fd0 /floppy
3. cd /floppy; cp /etc/profile .
# get an error and 2 kernel messages
4. cd /; umount /floppy
# at this stage the machine panic()'s 

>Fix:


>Release-Note:
>Audit-Trail:

From: <jkoshy@FreeBSD.org>
To: freebsd-gnats-submit@freebsd.org
Cc: ulianov@ns.csm.ro
Subject: Re: kern/10959: 3.1-STABLE crashes due to a floppy mount problem
Date: Wed, 11 Aug 1999 03:31:15 -0700 (PDT)

 I took a stab at reproducing and analysing this PR.  The good news is
 that the problem is reproducible in -current.
 
 Analysis: 
 [  mount a write-protected DOS floppy as read/write, 
    attempt to create some file,
    unmount floppy 
 ]
 
 The unmount operation fails as the floppy is write protected and writes 
 are not permitted.  Consequently some dirty buffers remain around.  However,
 `msdosfs_unmount()' will unconditionally set the `mnt_data' field of 
 the mount structure to 0, ignoring the error return from `VOP_CLOSE()'.
 
     "/sys/msdosfs/msdosfs_vfsops.c"
     805         error = VOP_CLOSE(pmp->pm_devvp,
     806                     (pmp->pm_flags&MSDOSFSMNT_RONLY) ? FREAD : FREAD | FWRITE,
     807                     NOCRED, p);
 	[...]
     811         mp->mnt_data = (qaddr_t)0;
     812         mp->mnt_flag &= ~MNT_LOCAL; 
 
 Later, the syncer process comes around and tries to write the dirty
 buffers back.  At this point, the `mnt_data' field of the mount
 structure has already been zero'ed.
 
     (kgdb) bt
     #0  msdosfs_sync (mp=0xc08b7a00, waitfor=3, cred=0xc05a4880, p=0xc5d328e0)
 	at ../../msdosfs/msdosfs_vfsops.c:881
     #1  0xc0177414 in sync_fsync (ap=0xc5d40f88) at ../../kern/vfs_subr.c:2901
     #2  0xc017545c in sched_sync () at vnode_if.h:499
     #3  0xc020d7a4 in fork_trampoline ()
     Cannot access memory at address 0x318000.
 
     (kgdb) p mp->mnt_data
     $38 = 0x0
 
     "/sys/msdosfs/msdosfs_vfsops.c"
     879         struct denode *dep;
     880         struct msdosfsmount *pmp = VFSTOMSDOSFS(mp);
     881         int error, allerror = 0;
 
 `pmp' thus is zero and the kernel panics when a deference through it
 is attempted at line 887.
 
     887         if (pmp->pm_fmod != 0) {
     888                 if (pmp->pm_flags & MSDOSFSMNT_RONLY) ...
 
 
 Questions:
 
 (a) at what point should we attempt to detect read-only media?
 (b) how do we ensure that a (forced?) unmount really scrubs all the
     buffers that are associated with the device being unmounted?
 
 Regards,
 Koshy
 <jkoshy@freebsd.org>
 

From: Bruce Evans <bde@zeta.org.au>
To: freebsd-gnats-submit@freebsd.org, jkoshy@freebsd.org
Cc:  
Subject: Re: kern/10959: 3.1-STABLE crashes due to a floppy mount problem
Date: Wed, 11 Aug 1999 22:02:40 +1000

 > I took a stab at reproducing and analysing this PR.  The good news is
 > that the problem is reproducible in -current.
 
 The good news is that you found a new bug :-).  Rev.1.196 of vfs_bio.c
 causes lots of problems by arranging for writes to be retried forever
 after an error.  Some of the problems are converted from endless retries
 to panics by filesystem bugs.
 
 > (a) at what point should we attempt to detect read-only media?
 
 Before opening it read-write.  Detection on every i/o is still required
 since removable media may become read-only (not to mention inaccessible)
 between i/o's.
 
 > (b) how do we ensure that a (forced?) unmount really scrubs all the
 >     buffers that are associated with the device being unmounted?
 
 (i) Don't forget to call vinvalbuf() on the mounted-on device in the
     filesystem's VOP_UNMOUNT() routine.  msdosfs_unmount() forgets to.
     Fixing this won't help much.  If the mount point has an unwritable
     block but no fs-specific vnodes have an unwritable block, then the
     unmount will hang retrying writes forever, despite being forced.
     The panic is probably rare even for mishandled floppies, because an
     unwritable block in an fs-specific vnode will cause a hang earlier.
 
 (ii) Don't allow the vinvalbuf() in (i) to fail.  It can fail in some
      cases, but these cases probably can't occur for devices.  Anyway,
      VOP_UNMOUNT() shouldn't proceed when vinvalbuf() fails.
 
 Bruce
 

From: <jkoshy@FreeBSD.org>
To: freebsd-gnats-submit@freebsd.org
Cc: Bruce Evans <bde@zeta.org.au>
Subject: Re: kern/10959: 3.1-STABLE crashes due to a floppy mount problem 
Date: Thu, 12 Aug 1999 02:20:10 -0700 (PDT)

 bde> The good news is that you found a new bug :-).  Rev.1.196 of vfs_bio.c
 bde> causes lots of problems by arranging for writes to be retried forever
 
 Using UFS instead of MSDOSFS leads to an (a) inability to unmount the
 floppy and (b) and endless series of retried writes to the floppy.
 No panic, though.
 
 jk> (a) at what point should we attempt to detect read-only media?
 
 bde> Before opening it read-write.  Detection on every i/o is still required
 bde> since removable media may become read-only (not to mention inaccessible)
 bde> between i/o's.
 
 Another point is that retrying writes in the presence of removable media 
 is risky as the physical media could have been changed under us.  We will
 need to check for a media change before attempting a read or write too.  
 
 Regards,
 Koshy
 <jkoshy@freebsd.org>
 

From: Bruce Evans <bde@zeta.org.au>
To: freebsd-gnats-submit@FreeBSD.org, jkoshy@FreeBSD.org
Cc: bde@zeta.org.au
Subject: Re: kern/10959: 3.1-STABLE crashes due to a floppy mount problem
Date: Thu, 12 Aug 1999 19:54:41 +1000

 >bde> The good news is that you found a new bug :-).  Rev.1.196 of vfs_bio.c
 >bde> causes lots of problems by arranging for writes to be retried forever
 >
 >Using UFS instead of MSDOSFS leads to an (a) inability to unmount the
 >floppy and (b) and endless series of retried writes to the floppy.
 >No panic, though.
 
 No problem if the machine is attended :-).  You can "fix" it by removing
 the write protection or by changing to disposable writable media.  The
 latter also works for hard write errors, but is only possible because the
 driver doesn't support media change (when the media changes, buffers for
 the original media should be held until the original media comes back, or
 discarded).
 
 Bruce
 

From: <jkoshy@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Bruce Evans <bde@zeta.org.au>, phk@FreeBSD.org
Subject: Re: kern/10959: 3.1-STABLE crashes due to a floppy mount problem 
Date: Thu, 12 Aug 1999 21:54:14 -0700 (PDT)

 The following band-aid patch fixes the panic reported in PR kern/10959,
 affecting both 3-STABLE and 4-CURRENT.  It avoids the panic by behaving
 more like the UFS code does.  Could you please review?
 
 I'm open to suggestions for a better fix for the panic.
 
 Thanks,
 Koshy
 <jkoshy@freebsd.org>
 
 Index: sys/msdosfs/msdosfs_vfsops.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/msdosfs/msdosfs_vfsops.c,v
 retrieving revision 1.46
 diff -u -r1.46 msdosfs_vfsops.c
 --- msdosfs_vfsops.c	1999/08/08 18:42:54	1.46
 +++ msdosfs_vfsops.c	1999/08/13 10:14:21
 @@ -779,7 +779,6 @@
  	if (error)
  		return error;
  	pmp = VFSTOMSDOSFS(mp);
 -	pmp->pm_devvp->v_specmountpoint = NULL;
  #ifdef MSDOSFS_DEBUG
  	{
  		struct vnode *vp = pmp->pm_devvp;
 @@ -805,6 +804,9 @@
  	error = VOP_CLOSE(pmp->pm_devvp,
  		    (pmp->pm_flags&MSDOSFSMNT_RONLY) ? FREAD : FREAD | FWRITE,
  		    NOCRED, p);
 +        if (error)
 +		return (error);
 +	pmp->pm_devvp->v_specmountpoint = NULL;
  	vrele(pmp->pm_devvp);
  	free(pmp->pm_inusemap, M_MSDOSFSFAT);
  	free(pmp, M_MSDOSFSMNT);
 
 
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Fri Aug 4 00:50:36 PDT 2000 
State-Changed-Why:  
This PR really represented two problems; panics on writes to read-only 
removable media and panics on interaction with msdosfs. 

The former remains a problem (see kern/10870).  The latter was fixed 
recently (see kern/17347). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=10959 
>Unformatted:
