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