tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Additional kmem_alloc debugging


Andrew Doran <> 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
> 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,

Home | Main Index | Thread Index | Old Index