panic: vfs_getopt: caller passed 'opts' as NULL

[Ulrich Spoerlein]

On 10/31/06, Kris Kennaway <kris at 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