| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This can happen when debug_malloc_init calls pool_init which calls
malloc (because the kernel is built with POOL_DIAGNOSTIC) which in turn
calls debug_malloc and debug_malloc just happens to trigger on all memory
allocations.
This allows us to run a kernel debugging _all_ allocations.
|
|
We'll never want to exec code in malloc mappings.
|
|
|
|
well (not at all) with shortages of the vm_map where the pages are mapped
(usually kmem_map).
Try to deal with it:
- group all information the backend allocator for a pool in a separate
struct. The pool will only have a pointer to that struct.
- change the pool_init API to reflect that.
- link all pools allocating from the same allocator on a linked list.
- Since an allocator is responsible to wait for physical memory it will
only fail (waitok) when it runs out of its backing vm_map, carefully
drain pools using the same allocator so that va space is freed.
(see comments in code for caveats and details).
- change pool_reclaim to return if it actually succeeded to free some
memory, use that information to make draining easier and more efficient.
- get rid of PR_URGENT, noone uses it.
|
|
misc pmap usage fixes.
|
|
(Look ma, I might have broken the tree)
|
|
|
|
|
|
useful changes (and a lot of cleanup). Bring in them.
|
|
From Heikki Korpela <heko@iki.fi>
|
|
Noted by: Heikki Korpela <heko@iki.fi>
|
|
The archs that didn't have a proper PMAP_NEW now have a dummy implementation
with wrappers around the old functions.
|
|
the size we are trying to allocate and not the size of the bucket
and malloc_debug is not capable of debugging a prticular bucket, only
a size, add a possibility to specify a size range.
|
|
|
|
that address.
|
|
|
|
|
|
Add an #error instead of breaking while compiling.
|
|
Make sure you read the docs (malloc(9)) before use.
|
