memguard monitoring of more than 1 memory_type?
Peter Jeremy
peterjeremy at optushome.com.au
Thu Feb 9 23:09:23 PST 2006
On Thu, 2006-Feb-09 22:55:14 +0100, Pawel Jakub Dawidek wrote:
>On Tue, Feb 07, 2006 at 11:14:08AM -0800, Steve Kargl wrote:
>+> Thanks for pointing out the obvious. I've read that manpage several
>+> times and somehow missed the word "particular". It's unfortunate
>+> that it can't monitor more than one type of memory allocation because
>+> the new pts code has either uncovered a latent bug in devfs or the
>+> pts patch is stomping on memory.
>
>It shouldn't be hard to implement. You need to change function
>memguard_cmp() in sys/vm/memguard.c, which decides which memory type
>should be monitored.
It's quite a bit messier than this. memguard.c privately stores a
record of which memory type is being debugged in vm_memguard_mtype
and vm_memguard_desc and doesn't bother passing this information via
the alloc/free hooks.
The current kern_malloc code looks like:
#ifdef DEBUG_MEMGUARD
if (memguard_cmp(mtp))
return memguard_alloc(size, flags);
#endif
If you are going to support multiple memory types, you need to pass
mtp to memguard_{alloc,free}() - in which case, you might as well
combine memguard_cmp() into these functions.
The easiest way to support multiple memory types is to hang the
memguard information off the struct malloc_type - except that means
that DEBUG_MEMGUARD changes the kernel ABI.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20060210/213c8c78/attachment.bin
More information about the freebsd-current
mailing list