> It simply requires you keep a second linked list of block information
> to use in "debug" mode. The current kmalloc is pretty useless at
> spotting scribbles and mistakes in kfree/kmalloc too.
Yes, it is possible to have a "debug mode" - I was messing around with
a hash-list (objects allocated from a 'Slab allocator'). This
mode removes one of the major advantages of the 'Lazy Buddy'; the
'Locally' free block. For a locally-free, no bit manipulation is needed
on the free, or a subsequent re-allocation of the block. This helps
to reduce the memory footprint, and hence reduces the amount of
'hot-data' in the hardware cache that is flushed by the allocation
process. Of course, this doesn't matter too much in "debug mode"....
My concern for the lack of checks was for a shipping version of Linux.
If there was a dynamically allocated memory bug, it would be difficult
to trace down if kmalloc()/kfree() didn't perform some reasonable
sanity checks. The allocator could be giving out a 512byte block
for a request of, say, 2k (as something previosuly lied that the
block being freeing was 2k...). This would corrupt the allocator even
more, leading to a panic in a _totally_ unrelated area.
I'm not fond of the idea that a central kernel service doesn't
validate itself.
markhe