From owner-freebsd-current@FreeBSD.ORG Fri Feb 10 07:09:23 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
X-Original-To: freebsd-current@freebsd.org
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C0CFD16A420;
Fri, 10 Feb 2006 07:09:23 +0000 (GMT)
(envelope-from peterjeremy@optushome.com.au)
Received: from mail21.syd.optusnet.com.au (mail21.syd.optusnet.com.au
[211.29.133.158])
by mx1.FreeBSD.org (Postfix) with ESMTP id B0D0743D49;
Fri, 10 Feb 2006 07:09:22 +0000 (GMT)
(envelope-from peterjeremy@optushome.com.au)
Received: from turion.vk2pj.dyndns.org
(c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236])
by mail21.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id
k1A79KID005161
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
Fri, 10 Feb 2006 18:09:20 +1100
Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])
by turion.vk2pj.dyndns.org (8.13.4/8.13.4) with ESMTP id k1A79JZX000852;
Fri, 10 Feb 2006 18:09:19 +1100 (EST)
(envelope-from peter@turion.vk2pj.dyndns.org)
Received: (from peter@localhost)
by turion.vk2pj.dyndns.org (8.13.4/8.13.4/Submit) id k1A79JCp000851;
Fri, 10 Feb 2006 18:09:19 +1100 (EST) (envelope-from peter)
Date: Fri, 10 Feb 2006 18:09:19 +1100
From: Peter Jeremy <peterjeremy@optushome.com.au>
To: Pawel Jakub Dawidek <pjd@freebsd.org>
Message-ID: <20060210070918.GA685@turion.vk2pj.dyndns.org>
References: <20060207183152.GA50629@troutmask.apl.washington.edu>
<20060207190121.GF19674@comp.chem.msu.su>
<20060207191408.GA50909@troutmask.apl.washington.edu>
<20060209215513.GA3590@garage.freebsd.pl>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK"
Content-Disposition: inline
In-Reply-To: <20060209215513.GA3590@garage.freebsd.pl>
X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc
User-Agent: Mutt/1.5.11
Cc: freebsd-current@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject: Re: memguard monitoring of more than 1 memory_type?
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Feb 2006 07:09:23 -0000
--CE+1k2dSO48ffgeK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
--=20
Peter Jeremy
--CE+1k2dSO48ffgeK
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFD7Dwc/opHv/APuIcRAkMAAJ4wSmDg3nCrOQmL40GAdQrOXbEjmgCgjWK+
K+3Iyo1z72KqorZ0lqG9tKs=
=JWx3
-----END PGP SIGNATURE-----
--CE+1k2dSO48ffgeK--