Re: panic: vfs_getopt: caller passed 'opts' as NULL
Kris Kennaway wrote: > > Nullfs seems more fragile than I initially thought ... > > It's just that compiling in the extra debugging (it might be > DEBUG_LOCKS or DEBUG_VFS_LOCKS, I forget which), causes the sizes of > structures to change, so when the module tries to fondle the structure > at a certain offset thinking it's accessing a certain field, it's > really fondling something else entirely and the kernel gets a nasty > surprise and panics. It is DEBUG_LOCKS. The DEBUG_VFS_LOCKS macro only enables additional code at runtime, it does not alter the ABI. Ironically, it is even documented in conf/NOTES. For the future, I have to remember that nullfs is a module. Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vfs_getopt: caller passed 'opts' as NULL
On Wed, Nov 01, 2006 at 11:57:48AM +0100, Ulrich Spoerlein wrote: > 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 ... It's just that compiling in the extra debugging (it might be DEBUG_LOCKS or DEBUG_VFS_LOCKS, I forget which), causes the sizes of structures to change, so when the module tries to fondle the structure at a certain offset thinking it's accessing a certain field, it's really fondling something else entirely and the kernel gets a nasty surprise and panics. Kris pgpT1GHhvPVUB.pgp Description: PGP signature
Re: panic: vfs_getopt: caller passed 'opts' as NULL
On Wed, Nov 01, 2006 at 11:57:48AM +0100, Ulrich Spoerlein wrote:
> On 10/31/06, Kris Kennaway <[EMAIL PROTECTED]> 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 ---
>
This is purely cosmetic, and shall make no harm. It is caused by
debugging check. Just ignore it, or use the following to silence
WITNESS:
Index: sys/fs/nullfs/null_subr.c
===
RCS file: /usr/local/arch/ncvs/src/sys/fs/nullfs/null_subr.c,v
retrieving revision 1.50
diff -u -r1.50 null_subr.c
--- sys/fs/nullfs/null_subr.c 22 Feb 2006 06:15:12 - 1.50
+++ sys/fs/nullfs/null_subr.c 1 Nov 2006 11:32:48 -
@@ -284,6 +284,8 @@
int lno;
{
struct null_node *a = VTONULL(vp);
+ struct vnode *lvp;
+ int refcnt;
#ifdef notyet
/*
* Can't do this check because vop_reclaim runs
@@ -295,7 +297,8 @@
panic("null_checkvp");
};
#endif
- if (a->null_lowervp == NULLVP) {
+ lvp = a->null_lowervp;
+ if (lvp == NULLVP) {
/* Should never happen */
int i; u_long *p;
printf("vp = %p, ZERO ptr\n", (void *)vp);
@@ -306,7 +309,10 @@
while (null_checkvp_barrier) /*WAIT*/ ;
panic("null_checkvp");
}
- if (vrefcnt(a->null_lowervp) < 1) {
+ VI_LOCK_FLAGS(lvp, MTX_DUPOK);
+ refcnt = lvp->v_usecount;
+ VI_UNLOCK(lvp);
+ if (refcnt < 1) {
int i; u_long *p;
printf("vp = %p, unref'ed lowervp\n", (void *)vp);
for (p = (u_long *) a, i = 0; i < 8; i++)
@@ -322,6 +328,6 @@
a->null_lowervp, vrefcnt(a->null_lowervp),
fil, lno);
#endif
- return a->null_lowervp;
+ return lvp;
}
#endif
pgpAy23CuXv4D.pgp
Description: PGP signature
Re: panic: vfs_getopt: caller passed 'opts' as NULL
On 10/31/06, Kris Kennaway <[EMAIL PROTECTED]> 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 DEBUG Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: panic: vfs_getopt: caller passed 'opts' as NULL
On 10/30/06, Kris Kennaway <[EMAIL PROTECTED]> 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vfs_getopt: caller passed 'opts' as NULL
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 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). Kris pgpYD5WtRbYdu.pgp Description: PGP signature
panic: vfs_getopt: caller passed 'opts' as NULL
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
