RELENG_6 from 30th October, trying to do two nullfs mounts from two amd-mounted directories (i.e., NFS mounts). Funny thing is, this amd/nfs/mount_nullfs is working on several other machines from a RELENG_6 checkout of 25th October. panic: vfs_getopt: caller passed 'opts' as NULL cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c8506780,c852c870,c8df3450,e8d0ca5c,...) at kdb_backtrace+0x29 panic(c089c395,c852c870,c8721b90,e8d0ca80,e8d0cadc,...) at panic+0x114 vfs_getopt(0,c8df3450,e8d0ca58,e8d0ca5c,0,...) at vfs_getopt+0x1d nullfs_mount(c8721b90,c8506780,0,c8df46c0,c8cd1c3c,...) at nullfs_mount+0x70 vfs_domount(c8506780,c852c870,c8433a40,0,c851cc50,c0971700,0,c089be7a,2a3) at vfs_domount+0x687 vfs_donmount(c8506780,0,c86ffd00,c86ffd00,0,...) at vfs_donmount+0x2ef nmount(c8506780,e8d0cd04) at nmount+0x8b syscall(3b,3b,3b,bfbfe3b4,bfbfec0c,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280ba4d7, esp 0xbfbfe33c, ebp = 0xbfbfebb8 --- KDB: enter: panic [thread pid 60225 tid 100085 ] Stopped at kdb_enter+0x2b: nop
On Mon, Oct 30, 2006 at 05:41:28PM +0200, Ulrich Spoerlein wrote:> RELENG_6 from 30th October, trying to do two nullfs mounts from two > amd-mounted directories (i.e., NFS mounts). > > Funny thing is, this amd/nfs/mount_nullfs is working on several other > machines from a RELENG_6 checkout of 25th October. > > panic: vfs_getopt: caller passed 'opts' as NULLThis can happen if you are using filesystem modules but your kernel is built with nonstandard options (DEBUG_*_LOCKS is a culprit, I think). Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061030/e885e51d/attachment.pgp
Ulrich Spoerlein
2006-Oct-31 07:49 UTC
Fwd: panic: vfs_getopt: caller passed 'opts' as NULL
On 10/30/06, Kris Kennaway <kris@obsecurity.org> wrote:> > panic: vfs_getopt: caller passed 'opts' as NULL > > This can happen if you are using filesystem modules but your kernel is > built with nonstandard options (DEBUG_*_LOCKS is a culprit, I think).Interesting, but no filesystem modules were involved. Infact, even geom_mirror and geom_label were statically built into the kernel. But the point is mood anyway, since I could not reproduce the problem. I tried again after rebooting the machine and everything went just fine ... I have to use the nullfs mounts on another machine shortly, let's see what happens there. Uli
On 10/31/06, Kris Kennaway <kris@obsecurity.org> wrote:> Note that they'll be demand-loaded if requested (e.g. if you try to > mount_nullfs). Maybe you or something else tried to mount such a > filesystem by accident? > > > But the point is mood anyway, since I could not reproduce the problem. > > I tried again after rebooting the machine and everything went just > > fine ... > > > > I have to use the nullfs mounts on another machine shortly, let's see > > what happens there.It reliably paniced in single user mode, with no other modules loaded at the time. But, I see now that nullfs.ko is loaded as a module, which might explain everything. I assumed it was built in. I rebooted to a kernel without DEBUG_VFS_LOCKS and it's happily using nullfs. I'll try once more with a debugging kernel, that has nullfs built in, but I'll guess the panic vanishes. Ok, with the attached kernel config, which includes nullfs, I get a duplicate lock, instead of a panic Trying to mount root from ufs:/dev/da0s1a acquiring duplicate lock of same type: "vnode interlock" 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2036 KDB: stack backtrace: kdb_backtrace(3,c894fa80,c0a47110,c0a47110,c09cb524,...) at kdb_backtrace+0x29 witness_checkorder(c8622d04,9,c0951b38,7f4) at witness_checkorder+0x578 _mtx_lock_flags(c8622d04,0,c0951b38,7f4,c840b590,...) at _mtx_lock_flags+0x78 vrefcnt(c8622c3c) at vrefcnt+0x20 null_checkvp(c8a7ed98,c093f5ae,215) at null_checkvp+0x56 null_lock(eb0bba80) at null_lock+0x66 VOP_LOCK_APV(c09c40a0,eb0bba80) at VOP_LOCK_APV+0x87 vn_lock(c8a7ed98,1002,c894fa80,c8a7ed98,c8a89224,...) at vn_lock+0xac nullfs_root(c88052e4,2,eb0bbaf8,c894fa80,0,8,0,c0a84040,0,c09513da,3dd) at nullfs_root+0x26 vfs_domount(c894fa80,c83e64c0,c8493490,0,c83fdad0,c0a38380,0,c09513da,2a3) at vfs_domount+0x975 vfs_donmount(c894fa80,0,c87f4e00,c87f4e00,0,...) at vfs_donmount+0x2ef nmount(c894fa80,eb0bbd04) at nmount+0x8b syscall(3b,3b,3b,bfbfe435,bfbfecc8,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280ba4d7, esp 0xbfbfe3fc, ebp = 0xbfbfec78 --- I grepped /sys for DEBUG_VFS_LOCKS and it seems to only add some additional KASSERTs, but not the one which triggered in the original panic. Nullfs seems more fragile than I initially thought ... Uli -------------- next part -------------- A non-text attachment was scrubbed... Name: DEBUG Type: application/octet-stream Size: 939 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061101/8e40e058/DEBUG.obj