From owner-freebsd-bugs Wed Aug 11 5:11:36 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 69409154CD for ; Wed, 11 Aug 1999 05:11:34 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA18480; Wed, 11 Aug 1999 05:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 11 Aug 1999 05:10:02 -0700 (PDT) Message-Id: <199908111210.FAA18480@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/10959: 3.1-STABLE crashes due to a floppy mount problem Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/10959; it has been noted by GNATS. From: Bruce Evans 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