Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Aug 2002 01:56:38 -0700 (PDT)
From:      Don Lewis <dl-freebsd@catspoiler.org>
To:        zipzippy@sonic.net
Cc:        current@FreeBSD.ORG
Subject:   Re: sleeping with "mntvnode" locked...
Message-ID:  <200208190856.g7J8ucwr027114@gw.catspoiler.org>
In-Reply-To: <20020819083238.GA739@blarf.homeip.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Aug, Alex Zepeda wrote:

> ../../../kern/kern_synch.c:454: sleeping with "mntvnode" locked from ../../../kern/vfs_subr.c:2789
> panic: from debugger
> cpuid = 0; lapic.id = 00000000
> -------
> 
> GNU gdb 5.2.0 (FreeBSD) 20020627
> This GDB was configured as "i386-undermydesk-freebsd"...

> #10 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
> #11 0xc016d1ed in db_panic () at ../../../ddb/db_command.c:449
> #12 0xc016d18c in db_command (last_cmdp=0xc03c4440, cmd_table=0x0, 
>     aux_cmd_tablep=0xc03bb4f0, aux_cmd_tablep_end=0xc03bb4f4)
>     at ../../../ddb/db_command.c:345
> #13 0xc016d25b in db_command_loop () at ../../../ddb/db_command.c:471
> #14 0xc016f692 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
> #15 0xc03257a8 in kdb_trap (type=3, code=0, regs=0xc9c17a28)
>     at ../../../i386/i386/db_interface.c:161
> #16 0xc0339fcc in trap (frame=
>       {tf_fs = -1071448040, tf_es = -1070006256, tf_ds = 16, tf_edi = 1, tf_esi = 0, tf_ebp = -910067092, tf_isp = -910067116, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 26, tf_trapno = 3, tf_err = 0, tf_eip = -1070441902, tf_cs = 8, tf_eflags = 642, tf_esp = -1, tf_ss = -910067060}) at ../../../i386/i386/trap.c:605
> #17 0xc0326bc8 in calltrap () at /var/tmp//ccTCRbXy.s:99
> #18 0xc023bb23 in witness_sleep (check_only=0, lock=0xc042bbe0, 
>     file=0xc038d8ee "../../../kern/kern_synch.c", line=454)
>     at ../../../kern/subr_witness.c:927
> #19 0xc022653c in msleep (ident=0xc223a7b8, mtx=0xc042bbe0, priority=72, 
>     wmesg=0x0, timo=0) at ../../../kern/kern_synch.c:454
> #20 0xc0217497 in acquire (lkp=0xc223a7b8, extflags=16777280, wanted=1536)
>     at ../../../kern/kern_lock.c:168
> #21 0xc02177d0 in lockmgr (lkp=0xc223a7b8, flags=16842754, interlkp=0x1000040, 
>     td=0xc2667480) at ../../../kern/kern_lock.c:381
> #22 0xc025c758 in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:279
> #23 0xc02ee573 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2770
> #24 0xc026c36a in vn_lock (vp=0xc223a6f0, flags=65538, td=0xc2667480)
>     at vnode_if.h:871
> #25 0xc0263665 in vrele (vp=0xc223a6f0) at ../../../kern/vfs_subr.c:1963
> #26 0xc0264a5a in sysctl_vnode (oidp=0xc03f9aa0, arg1=0x0, arg2=0, 
>     req=0xc9c17c08) at ../../../kern/vfs_subr.c:2835
> #27 0xc0228826 in sysctl_root (oidp=0x0, arg1=0xc9c17cb4, arg2=2, 
>     req=0xc9c17c08) at ../../../kern/kern_sysctl.c:1147
> #28 0xc02289e4 in userland_sysctl (td=0x0, name=0xc9c17cb4, namelen=2, 
>     old=0xc9c17c60, oldlenp=0xa, inkernel=0, new=0xc9c17c30, newlen=0, 
>     retval=0xc9c17cb0) at ../../../kern/kern_sysctl.c:1242
> #29 0xc02288a9 in __sysctl (td=0xc2667480, uap=0xc9c17d14)
>     at ../../../kern/kern_sysctl.c:1181
> #30 0xc033a7a4 in syscall (frame=
>       {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077939888, tf_esi = 2, tf_ebp = -1079200088, tf_isp = -910066316, tf_ebx = -1079200048, tf_edx = -1077937728, tf_ecx = -1077939912, tf_eax = 202, tf_trapno = 12, tf_err = 2, tf_eip = 134575943, tf_cs = 31, tf_eflags = 658, tf_esp = -1079200132, tf_ss = 47})
>     at ../../../i386/i386/trap.c:1050
> #31 0xc0326c1d in Xint0x80_syscall () at /var/tmp//ccTCRbXy.s:141
> ---Can't read userspace from dump, or kernel process---> 
> (kgdb) quit
> 
> Anything I can do here to help?

This is getting triggered by the kern.vnode sysctl.  SMP or UP?  Offhand
I have a hard time seeing how the sequence
	vref(vp)
	do cpu bound stuff
	vrele(vp)
would do anything other than increment and decrement the vnode reference
count on a UP box.  Even on an SMP box, what are the chances that some
other process would vrele() a vnode while the sysctl handler had a
reference to it and was copying some data from it?

Does "sysctl kern.vnode" trigger this panic while the machine is idle?


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208190856.g7J8ucwr027114>