On Wed, 25 Jun 2003 16:44:56 -0400 (EDT) Robert Watson <[EMAIL PROTECTED]> 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 socketd _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
