Messages in this thread | | | From | Mark.Hemment@uniplex ... | Date | Tue, 11 Jun 96 10:48:25 +0100 | Subject | Re: Ideas for v2.1 |
| |
> From: alan >> o Freeing performs only the most basic sanity checks on the >> given address. >> The second point will probably kill the 'Lazy-Buddy' off for Linux...
> 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
| |