This is from HardenedBSD's OPNSense work at https://github.com/HardenedBSD/hardenedBSD/tree/hardened/experimental/opnsense-10-stable uname: FreeBSD 10.2-BETA1-HBSD #0 bf2d0b1(hardened/experimental/opnsense-10-stable): Thu Jul 16 20:35:06 EDT 2015 root@opnsense-dev:/usr/obj/opnsense/usr/src/sys/SMP-HARDENEDBSD amd6 I'm at commit bf2d0b176566519b95f21d01cc101f4b60247ab8 in that repo/branch. This is on amd64. I've uploaded the bad build to https://hardenedbsd.org/~shawn/opnsense/bad_builds/2015-07-18_HardenedBSD-hbsd-exp-03_OPNSense-serial-generic-amd64.img Boot log: Trying to mount root from ufs:/dev/ufs/HardenedBSD_Install [ro,noatime]... Mounting filesystems... tunefs: soft updates set tunefs: file system reloaded camcontrol: subcommand "identify" requires a valid device identifier panic: __lockmgr_args: recursing on non recursive lockmgr tmpfs @ /usr/src/sys/kern/vfs_subr.c:2174 cpuid = 1 KDB: enter: panic [ thread pid 20959 tid 100107 ] Stopped at kdb_enter+0x3e: movq $0,kdb_why db> bt Tracing pid 20959 tid 100107 td 0xfffff80006680000 kdb_enter() at kdb_enter+0x3e/frame 0xfffffe00fd9c3200 vpanic() at vpanic+0x146/frame 0xfffffe00fd9c3240 panic() at panic+0x43/frame 0xfffffe00fd9c32a0 __lockmgr_args() at __lockmgr_args+0x1151/frame 0xfffffe00fd9c33b0 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe00fd9c33d0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe00fd9c3400 _vn_lock() at _vn_lock+0xaa/frame 0xfffffe00fd9c3470 vget() at vget+0x67/frame 0xfffffe00fd9c34b0 tmpfs_alloc_vp() at tmpfs_alloc_vp+0x207/frame 0xfffffe00fd9c3530 tmpfs_lookup() at tmpfs_lookup+0x3d5/frame 0xfffffe00fd9c3590 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xf1/frame 0xfffffe00fd9c35c0 vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfffffe00fd9c3620 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe00fd9c3650 relookup() at relookup+0xa1/frame 0xfffffe00fd9c36b0 unionfs_relookup() at unionfs_relookup+0x102/frame 0xfffffe00fd9c3710 unionfs_relookup_for_delete() at unionfs_relookup_for_delete+0x56/frame 0xfffffe00fd9c37a0 unionfs_rmdir() at unionfs_rmdir+0xce/frame 0xfffffe00fd9c3800 VOP_RMDIR_APV() at VOP_RMDIR_APV+0xf7/frame 0xfffffe00fd9c3830 kern_rmdirat() at kern_rmdirat+0x1b9/frame 0xfffffe00fd9c39a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe00fd9c3ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00fd9c3ab0 --- syscall (137, FreeBSD ELF64, sys_rmdir), rip = 0x156d6ae08ca, rsp = 0x7ffffbe2c988, rbp = 0x7ffffbe2c9b0 ---
This ought to fix it: https://github.com/opnsense/src/commit/d9cb17f050e083 I was reluctant to file a PR because I couldn't reproduce on a vanilla FreeBSD. Note the fix is from March.
Need to pick this back up. Would like to see this brought into in 11-CURRENT if there are no objections?
(In reply to Franco Fichtner from comment #1) tmpfs change is completely wrong, there is no reason for tmpfs vnode lock to be recursive. Unionfs is broken architecturally, it was so for the whole its existence, which is cause of this backtrace and many other issues you could get with the unionfs breaking all assumptions of VFS and filesystems.
Cool, what is the proposed workaround or replacement in this case? :)
(In reply to Franco Fichtner from comment #4) > Cool, what is the proposed workaround or replacement in this case? :) As Kib pointed out, Unionfs is plain broken. I know of some people who are hacking on it in their spare time, but I don't expect it to be fixed any time soon.
So, to wrap this up, I have this one last question: Are there any bad side effects from using this patch as a workaround? Thanks in advance, Franco