Potential fix for panic during shutdown.

When a tty is revoked, the opencount of its associated vnode is forced to
zero and calling vop_stdclose() on this vnode causes a panic.  Call therefore
vop_stdclose() from spec_close() if and only if the opencount is strictly
positive.

I haven't managed to reproduce the original panic locally, hence the
"potential" above.

Reported-by: Thomas Nikolajsen <thomas.nikolajsen@mail.dk>
Dragonfly-bug: <http://bugs.dragonflybsd.org/issue715>

diff --git a/sys/vfs/specfs/spec_vnops.c b/sys/vfs/specfs/spec_vnops.c
index 5971017..97b5cf9 100644 (file)
--- a/sys/vfs/specfs/spec_vnops.c
+++ b/sys/vfs/specfs/spec_vnops.c
@@ -746,12 +746,11 @@ spec_close(struct vop_close_args *ap)
 
        /*
         * Track the actual opens and closes on the vnode.  The last close
-        * disassociates the rdev.  If the rdev is already disassociated 
-        * the vnode might have been revoked and no further opencount
-        * tracking occurs.
+        * disassociates the rdev.  If the rdev is already disassociated or the
+        * opencount is already 0, the vnode might have been revoked and no
+        * further opencount tracking occurs.
         */
        if (dev) {
-               /*KKASSERT(vp->v_opencount > 0);*/
                if (dev_ref_debug) {
                        kprintf("spec_close: %s %d\n",
                                dev->si_name, vp->v_opencount - 1);
@@ -760,7 +759,8 @@ spec_close(struct vop_close_args *ap)
                        v_release_rdev(vp);
                release_dev(dev);
        }
-       vop_stdclose(ap);
+       if (vp->v_opencount > 0)
+               vop_stdclose(ap);
        return(error);
 }