lkml.org 
[lkml]   [1996]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.126 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site