Hi, we sometimes see a panic "unmount: dangling vnode" when rebooting a 6.1 system with softdep.
I have hacked some diagnostic panics until I got these traces from the reboot and update process. Reboot: sleep_finish() at sleep_finish+0xb1 tsleep() at tsleep+0x154 biowait() at biowait+0x46 bwrite() at bwrite+0x10d ffs_update() at ffs_update+0x2bd VOP_FSYNC() at VOP_FSYNC+0x3c ffs_flushfiles() at ffs_flushfiles+0xb9 softdep_flushfiles() at softdep_flushfiles+0x4e ffs_unmount() at ffs_unmount+0x49 dounmount_leaf() at dounmount_leaf+0x8b dounmount() at dounmount+0xb2 vfs_unmountall() at vfs_unmountall+0x72 vfs_shutdown() at vfs_shutdown+0x79 boot() at boot+0x144 reboot() at reboot+0x30 sys_reboot() at sys_reboot+0x5e syscall() at syscall+0x21f Update: *115878 74431 0 0x14000 0x200 0 update Debugger() at Debugger+0x9 panic() at panic+0xfe insmntque() at insmntque+0x86 getnewvnode() at getnewvnode+0x192 ffs_vget() at ffs_vget+0x8b handle_workitem_remove() at handle_workitem_remove+0x4c process_worklist_item() at process_worklist_item+0xf5 softdep_process_worklist() at softdep_process_worklist+0x169 sched_sync() at sched_sync+0xfb At reboot all vnodes are flushed, but when it sleeps, the update process has a chance to create new dirty vnodes. Resolving soft dependencies adds vnodes to the dirty list. In softdep_flushfiles() vnodes and softdep are flushed in a loop. But if they sleep, it is not guaranteed that all vnodes have been flushed when the softdep worklist flush reports that nothing has been done. My solution is to do a final vnode flush after the softdep worklist has been flushed. Then the dirty list is empty and the final check in dounmount_leaf() does not panic. ok? bluhm Index: ufs/ffs/ffs_softdep.c =================================================================== RCS file: /data/mirror/openbsd/cvs/src/sys/ufs/ffs/ffs_softdep.c,v retrieving revision 1.135 diff -u -p -r1.135 ffs_softdep.c --- ufs/ffs/ffs_softdep.c 7 Nov 2016 00:26:33 -0000 1.135 +++ ufs/ffs/ffs_softdep.c 9 Oct 2017 22:19:39 -0000 @@ -904,6 +904,14 @@ softdep_flushfiles(struct mount *oldmnt, break; } /* + * If the reboot process sleeps during the loop, the update + * process may call softdep_process_worklist() and create + * new dirty vnodes at the mount point. Call ffs_flushfiles() + * again after the loop has flushed all soft dependencies. + */ + if (error == 0) + error = ffs_flushfiles(oldmnt, flags, p); + /* * If we are unmounting then it is an error to fail. If we * are simply trying to downgrade to read-only, then filesystem * activity can keep us busy forever, so we just fail with EBUSY.