[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Additional kmem_alloc debugging
Andrew Doran <ad%netbsd.org@localhost> wrote:
> This adds basic verification to kmem_alloc/kmem_free somewhat like you get
> with ElectricFence. It's enabled with the DEBUG kernel option AND a debugger
> boot -d
> db> w kmem_guard_depth 0t30000
> db> c
Simple and looks good.
I have tried kernel with it (patch, as-is, does not compile), just a simple
run have not found anything. :)
How about adding KMEMORY_DEBUG or similar option?
> The above tells it to queue up to 60000 pages of unmapped KVA to catch
> use-after-free type errors. Memory backing a freed item is unmapped and the
> kernel VA space pushed onto a FIFO. The VA space will not be reused until
> another 30k items have been freed. Until reused the kernel can catch invalid
> acceses and panic with a page fault.
How about adding uvm_kmguard_flush(), which would allow to free all pages in
the FIFO list? I think it might be useful.
> - It has a severe impact on performance.
> - It wants a 64-bit machine with lots of RAM.
> - It does not handle objects larger than PAGE_SIZE.
Eats a lot of memory and KVA, but I have not found it very slow!
There is one more point, not entirely related with this topic. LOCKDEBUG,
KMGUARD and other options use a lot of resources (where is effect is reduced
concurrency, which means harder to hit locking issues). How about enforcing
some debugging granularity?
Main Index |
Thread Index |