Re: 2.6.16-rc5-mm2 - yet another memory leak...
On Mon, 06 Mar 2006 14:18:47 EST, Steve Grubb said:
On Sunday 05 March 2006 19:38, Valdis.Kletnieks(a)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.
Attachments:
- attachment.sig (application/pgp-signature — 228 bytes)