Re: Additional kmem_alloc debugging

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Hello,

Andrew Doran <ad%netbsd.org@localhost> wrote:
> http://www.netbsd.org/~ad/kmguard.diff
> 
> 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
> command:
> 
>       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.

> Limitations:
> 
> - 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!

> 
> Comments?
>

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?

-- 
Best regards,
Mindaugas