malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following
non-sleepable locks held
Willem Jan Withagen
wjw at withagen.nl
Mon Jul 5 11:26:16 PDT 2004
From: "Robert Watson" <rwatson at freebsd.org>
> On Mon, 5 Jul 2004, Willem Jan Withagen wrote:
>
> > It's not a LOR, but almost looks like one.... it could also be
> > harmless, since it only delays the server (because it is logging to a
> > serial console???)
>
> Do you have a stack trace available for this? I've cleaned up a few, but
> not all, of the known M_WAITOK with a mutex held cases, but there may well
> be more. I know Bruce Simpson has also been working on at least one.
Other than what is included below, nothing further was on the console.
But it is relatively simple to reproduce.... compiling on an NFS mount does the
trick. So if you want me to do other things, let me know..
Currently running with INVARIANTS, WITNESS, WITNESS_SKIPSPIN, DIAGNOSTIC, DDB,
DDB_TRACE ......
--WjW
> > ----------------
> > malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following
non-sleepable
> > locks held:
> > exclusive sleep mutex so_rcv r = 0 (0xffffff006174a6f8) locked @
/home2/src/sys/
> > kern/uipc_socket.c:917
> > Stack backtrace:
> > backtrace() at backtrace+0x17
> > witness_warn() at witness_warn+0x297
> > uma_zalloc_arg() at uma_zalloc_arg+0x59
> > m_copym() at m_copym+0x118
> > soreceive() at soreceive+0x9a4
> > nfs_receive() at nfs_receive+0x29f
> > nfs_reply() at nfs_reply+0x46
> > nfs_request() at nfs_request+0x374
> > nfs_writerpc() at nfs_writerpc+0x22b
> > nfs_doio() at nfs_doio+0x4a0
> > nfssvc_iod() at nfssvc_iod+0x1c4
> > fork_exit() at fork_exit+0xd1
> > fork_trampoline() at fork_trampoline+0xe
> > --- trap 0, rip = 0, rsp = 0xffffffffb4019d00, rbp = 0 ---
More information about the freebsd-current
mailing list