Re: malloc(M_NOWAIT) issues.

[Max Laier <max@xxxxxxxxxxxxxx>]

On Monday 19 January 2004 00:28, Matthew Dillon wrote:
>     An interesting thread (search for '[CHECKER]' in freebsd-hackers
> led me to review our use of M_NOWAIT in malloc().
>
>     In a nutshell, most of the M_NOWAIT uses are incorrect.  In
> particular, much of the CAM code runs from an interrupt or a software
> interrupt and almost universally uses M_NOWAIT for its allocations,
> with dire consequences if/when allocations fail.
>
>     I think I've come up with a solution!  The reason M_NOWAIT is used
> is primarily because an interrupt thread may be preempting a normal
> thread and cannot safely manipulate 'cache' pages in the VM page
> queues.  This is because reusing a cache page requires messing around
> with the VM Object the cache page resides in.  So M_NOWAIT causes
> kmem_malloc() to only pull pages out of the VM 'free' page queue.  At
> the same time it is allowed to actually exhaust the free page queue
> whereas normal allocations are not allowed to completely exhaust the
> free page queue.

I think that quite a few malloc(...M_NOWAIT) and mget(M_DONTWAIT...) are  
- in 5.x at least - subject to the following comment in mutex(9):

> Sleeping
> Sleeping while holding a mutex (except for Giant) is almost never safe
> and should be avoided.  There are numerous assertions which will fail if
> this is attempted.

with devastating results in most cases. WITNESS will even warn of 
malloc(...M_WAITOK) while holding a mutex.

While this is something pretty 5.x specifc, I though I just report this as 
it really tasted wrong to me when I came across it for the first time 
(while doing pfil_hook locking for 5.x). But I found that you get used to 
malloc with M_NOWAIT whenever you even _might_ be holding a mutex.

FWIW, mbuf(9) alloc functions need a redo with similar resoning. There are 
many places where a failed mget() will cause a panic.

-- 
Best regards,				| max@xxxxxxxxxxxxxx
Max Laier				| ICQ #67774661
http://pf4freebsd.love2party.net/	| mlaier@EFnet