From owner-freebsd-bugs  Wed Jan 15 05:57:09 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id FAA02932
          for bugs-outgoing; Wed, 15 Jan 1997 05:57:09 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA02925;
          Wed, 15 Jan 1997 05:57:00 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id AAA24268; Thu, 16 Jan 1997 00:51:05 +1100
Date: Thu, 16 Jan 1997 00:51:05 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199701151351.AAA24268@godzilla.zeta.org.au>
To: bugs@freebsd.org
Subject: malloc(..., M_WAITOK) found harmful
Cc: dyson@freebsd.org, wollman@freebsd.org
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I added some debugging code to malloc() to find calls made with M_WAITOK
at a suspiciously high spl.  After ignoring hundreds of problems when
cold == 1, the following serious problem appeared first:

...
changing root device to wd0a
DEVFS: ready to run
M_NOWAIT malloc called at high spl 0xc003849a
Debugger("")
Stopped at      _Debugger+0x36: movb    $0,_in_Debugger.94
db> t
_Debugger(f0119706,f01196de,c003849a) at _Debugger+0x36
_malloc(24,1f,0,f0642000,f063ec80) at _malloc+0x16f
_vm_map_entry_create(f063ec80,f063ec80,f063ec84,1000,c003849a) at _vm_map_entry_create+0x164
_vm_map_insert(f063ec80,f0223084,682000,0,f0641000) at _vm_map_insert+0x1ec
_kmem_malloc(f063ec80,1000,1,80000000,efbfff90) at _kmem_malloc+0x10c
_m_clalloc(1,1) at _m_clalloc+0x2e
_mbinit(0) at _mbinit+0x38
_main(efbfffb8,efbfff07,efbffff4,f01d34bc,f0224950,f028c000,7ff000,f01d34fc,30,284f00,288000,288000,e5700407) at _main+0x8b
begin() at begin+0x43

Here mbinit() calls m_clalloc() with the M_DONTWAIT flag and m_clalloc()
calls kmem_malloc() with the M_NOWAIT flag, but the flag is not passed
on to vm_map_insert() and vm_map_entry_create() eventually calls malloc()
with the M_WAITOK flag.  vm_map_create() always uses M_WAITOK.

After initialization, most of the problems seem to be in my
clist_alloc_cblocks() code (I knew about this - its callers are not
prepared for it to wait, and expect spltty() to prevent sleeping),
and in accept() and soconnect() (e.g., accept1() calls falloc() which
calls malloc(..., M_WAITOK)).

Bruce