On Mon, 06 Mar 2006 14:18:47 EST, Steve Grubb said: > On Sunday 05 March 2006 19:38, Valdis Kletnieks vt edu wrote: > > Yet another leak - this time it seems to be the audit_socketcall() > > in sys_socketcall(). > > I've been looking through the code and don't see the leak. audit_free_context > calls audit_free_aux which appears to do the right thing. Does anyone else > see the leak? I wonder if the problem is that audit_free_context() never gets hit for some things. I didn't get warm and fuzzies about the fact that *all* calls to sys_socketcall() end up hitting it - a few lines later we have a huge switch: case SYS_SOCKET: case SYS_BIND: case SYS_CONNECT: case SYS_LISTEN: case SYS_ACCEPT: case SYS_GETSOCKNAME: case SYS_GETPEERNAME: case SYS_SOCKETPAIR: case SYS_SEND: case SYS_SENDTO: case SYS_RECV: case SYS_RECVFROM: case SYS_SHUTDOWN: case SYS_SETSOCKOPT: case SYS_GETSOCKOPT: case SYS_SENDMSG: case SYS_RECVMSG: default: Does one of these paths manage to escape hitting the cleanup, because it doesn't do anything that's LSPP auditable? > > (Meta-question - why am I tripping over all these leaks?) > > Cause no one else is testing like you. How are you finding the leaks? More > people could watch for these if you tell us what you are doing. BTW, thanks > for pointing them out. I build the kernel on my laptop, I boot it, and after a few hours, I see a growing number in /proc/meminfo for slab, and a matching odd entry in /proc/slabinfo. That's why I don't understand why I've hit 3 leaks of this magnitude - is everybody else testing this code running it for just short tests on BHI (Big Honkin' Iron) hardware, rather than trying to stay up for a weekend on a laptop class box? I've been up and running for an hour, and I got this: % grep size-32 /proc/slabinfo size-32 118052 118104 44 84 1 : tunables 32 16 0 : slabdata 1406 1406 0 : globalstat 138932 118052 1407 1 0 1 0 0 : cpustat 640001 9763 530408 1305 % echo "size-32 0 0 0" >| /proc/slabinfo % dmesg -c -s 16000000 > /tmp/f2 % ls -l /tmp/f2 8736 -rw-r--r-- 1 root root 8929222 Mar 6 14:36 /tmp/f2 % grep ' obj ' /tmp/f2 | cut -f2 -d: | sort | uniq -c | sort -nr | head 105187 c02e72b2 <sys_socketcall+0x4d/0x186> 8412 c01da799 <cond_insertf+0xb5/0x10d> 4949 c01d5007 <ebitmap_read+0xc1/0x1ce> 2136 c01d52b2 <hashtab_insert+0x64/0xc3> 1873 c01d795f <policydb_read+0x2b9/0xbbe> 1454 c01d72ea <type_read+0x1e/0xde> 1153 c01cf596 <selinux_file_alloc_security+0x25/0x47> 353 c0151a85 <cache_alloc_refill+0x35c/0x59f> 288 c01d67e0 <perm_read+0x1e/0xcf> 268 c018c5c4 <sysfs_create_link+0x4a/0xda> And in the 20 minutes I spent composing this mail, it's grown: % grep size-32 /proc/slabinfo size-32 146496 146496 44 84 1 : tunables 32 16 0 : slabdata 1744 1744 0 : globalstat 168336 146496 1745 1 0 1 0 0 : cpustat 779819 11855 643828 1365 Yowza.
Description: PGP signature