https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288345
--- Comment #9 from Mark Johnston <[email protected]> --- In both cases we are getting stuck removing a tmpfs mount: umount - mi_switch+0xbd _sleep+0x1f3 vfs_write_suspend+0xe2 vfs_write_suspend_umnt+0x1c tmpfs_unmount+0x23 dounmount+0x789 kern_unmount+0x2f5 amd64_syscall+0x117 fast_syscall_common+0xf8 and there is an ld thread blocked on a vnode lock: ld - mi_switch+0xbd sleeplk+0x10a lockmgr_xlock_hard+0x398 _vn_lock+0x47 tmpfs_alloc_vp+0x2f3 tmpfs_alloc_file+0x20c tmpfs_create+0x2b VOP_CREATE_APV+0x25 vn_open_cred+0x3dd openatfp+0x262 sys_open+0x28 amd64_syscall+0x117 fast_syscall_common+0xf8 So we allocated a new tmpfs node and a vnode to go with it, but something else has the vnode locked. When this deadlock arises again, it'd be good to get a kernel dump so we can see who's holding the lock. I can't see any obvious candidates in the procstat output, e.g., the vnlru thread is idle. If you have a dumpdev configured, it should be enough to just panic the system with `sysctl debug.kdb.panic=1` after the deadlock happens. -- You are receiving this mail because: You are the assignee for the bug.
