Date: Mon, 30 Aug 2004 00:25:41 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: current@freebsd.org Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 Message-ID: <Pine.NEB.3.96L.1040830002424.1492A-100000@fledge.watson.org> In-Reply-To: <20040829145445.GB24815@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Could you try the following patch:
Index: ng_socket.c
===================================================================
RCS file: /home/ncvs/src/sys/netgraph/ng_socket.c,v
retrieving revision 1.53
diff -u -r1.53 ng_socket.c
--- ng_socket.c 31 Jul 2004 21:32:55 -0000 1.53
+++ ng_socket.c 30 Aug 2004 04:17:38 -0000
@@ -300,7 +300,9 @@
/* Not found, try to load it as a loadable module */
snprintf(filename, sizeof(filename), "ng_%s", mkp->type);
+ mtx_lock(&Giant);
error = linker_load_module(NULL, filename, NULL, NULL, &lf);
+ mtx_unlock(&Giant);
if (error != 0) {
FREE(msg, M_NETGRAPH_MSG);
goto release;
This causes Giant to be acquired in the event we enter the linker code
(and hence VFS code) via netgraph ngc_send(). It should be safe in this
context as we enter protocol send routines without mutexes held (i.e., why
we're also able to do blocking memory allocation here.)
Thanks!
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Principal Research Scientist, McAfee Research
On Sun, 29 Aug 2004, Gleb Smirnoff wrote:
> #21 0xc055ecc0 in kdb_enter (msg=0x0) at cpufunc.h:56
> #22 0xc0542dd5 in panic (fmt=0xc06dd9db "mutex %s not owned at %s:%d")
> at /usr/src/sys/kern/kern_shutdown.c:536
> #23 0xc053914c in _mtx_assert (m=0xc07402a0, what=0,
> file=0xc06e6fbd "/usr/src/sys/kern/vfs_vnops.c", line=120)
> at /usr/src/sys/kern/kern_mutex.c:736
> #24 0xc05b165c in vn_open_cred (ndp=0xd0aafaa0, flagp=0xd0aaf97c, cmode=0,
> cred=0xc1ad1300, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:120
> #25 0xc05b1613 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
> at /usr/src/sys/kern/vfs_vnops.c:91
> #26 0xc05343a0 in linker_hints_lookup (
> path=0xc0714020 "/boot/kernel;/boot/modules", pathlen=12,
> modname=0xd0aafb74 "ng_tee", modnamelen=6, verinfo=0x0)
> at /usr/src/sys/kern/kern_linker.c:1473
> #27 0xc0534947 in linker_search_module (modname=0xd0aafb74 "ng_tee",
> modnamelen=6, verinfo=0x0) at /usr/src/sys/kern/kern_linker.c:1593
> #28 0xc0534b19 in linker_load_module (kldname=0x0,
> modname=0xd0aafb74 "ng_tee", parent=0x0, verinfo=0x0, lfpp=0xd0aafb70)
> at /usr/src/sys/kern/kern_linker.c:1682
> *** these "??" should be:
> ngc_send() in /usr/src/sys/netgraph/ng_socket.c
> #29 0xc1b71d17 in ?? ()
> #30 0x00000000 in ?? ()
> #31 0xd0aafb74 in ?? ()
> #32 0x00000000 in ?? ()
> #33 0x00000000 in ?? ()
> #34 0xd0aafb70 in ?? ()
> #35 0xc1ae6c38 in ?? ()
> #36 0x00000000 in ?? ()
> #37 0xc1789080 in ?? ()
> #38 0xc06dd88c in ?? ()
> #39 0x745f676e in ?? ()
> #40 0xc1006565 in ?? ()
> #41 0xd0aafc48 in ?? ()
> #42 0xd0aafcbc in ?? ()
> #43 0xc0548b25 in uiomove (cp=0xc17a8654, n=0, uio=0xc1692140)
> at /usr/src/sys/kern/kern_subr.c:164
> #44 0xc0585621 in sosend (so=0xc17a8654, addr=0xc156a5d0, uio=0xd0aafc48,
> top=0xc1609300, control=0x0, flags=0, td=0xc173d840)
> at /usr/src/sys/kern/uipc_socket.c:799
> #45 0xc058c0ac in kern_sendit (td=0xc173d840, s=3, mp=0xd0aafcc4, flags=0,
> control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:738
> #46 0xc058bf3b in sendit (td=0x0, s=0, mp=0xd0aafcc4, flags=0)
> at /usr/src/sys/kern/uipc_syscalls.c:682
> #47 0xc058c22b in sendto (td=0x0, uap=0x0)
> at /usr/src/sys/kern/uipc_syscalls.c:795
> #48 0xc0697c50 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077946376, tf_esi = -1077946382, tf_ebp = -1077945832, tf_isp = -794100364, tf_ebx = 671649088, tf_edx = -1077946384, tf_ecx = 5, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671984639, tf_cs = 31, tf_eflags = 514, tf_esp = -1077946452, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1004
> #49 0xc06851bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201
>
>
> --
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040830002424.1492A-100000>