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