Date: Wed, 11 Aug 1999 05:10:02 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/10959: 3.1-STABLE crashes due to a floppy mount problem Message-ID: <199908111210.FAA18480@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/10959; it has been noted by GNATS.
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908111210.FAA18480>