DragonFly kernel List (threaded) for 2004-01
Re: malloc(M_NOWAIT) issues.
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 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