Date: Thu, 26 Jun 2003 15:11:13 +0200 From: Socketd <db@traceroute.dk> To: Robert Watson <rwatson@freebsd.org>, current@freebsd.org Subject: Re: FreeBSD 5.1-Release freezes Message-ID: <20030626151113.28866ac9.db@traceroute.dk> In-Reply-To: <Pine.NEB.3.96L.1030625164029.58599A-100000@fledge.watson.org> References: <20030625191652.289ba4db.db@traceroute.dk> <Pine.NEB.3.96L.1030625164029.58599A-100000@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
On Wed, 25 Jun 2003 16:44:56 -0400 (EDT) Robert Watson <rwatson@freebsd.org> wrote: > The code most likely to cause a memory leak in the MAC Framework is > the label management code, since that's the only code that really does > much in the way of memory allocaiton. Try compiling options MAC_DEBUG > into your kernel, which causes the MAC Framework to track the number > of labels it has allocated/free'd in a series of variables: > > static unsigned int nmacmbufs, nmaccreds, nmacifnets, nmacbpfdescs, > nmacsockets, nmacmounts, nmactemp, nmacvnodes, nmacdevfsdirents, > nmacipqs, nmacpipes, nmacprocs; After running a few commands, ssh logins and loading mac_seeotheruids we now have: security.mac.debug.label_fallback: 0 security.mac.debug.counters.mbufs: 0 security.mac.debug.counters.creds: 17 security.mac.debug.counters.ifnets: 3 security.mac.debug.counters.ipqs: 0 security.mac.debug.counters.bpfdescs: 0 security.mac.debug.counters.sockets: 7 security.mac.debug.counters.pipes: 2 security.mac.debug.counters.procs: 63 security.mac.debug.counters.mounts: 6 security.mac.debug.counters.temp: 0 security.mac.debug.counters.vnodes: 524 security.mac.debug.counters.devfsdirents: 99 Loading mac_seeotheruids made vnodes increase a little, but it has (very slowly) been increasing and as you can see is now at 524 (don't know if this means anything). br socketdhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030626151113.28866ac9.db>