2.6.16-rc5-mm2 - yet another memory leak...

[Valdis.Kletnieks at vt.edu]

On Mon, 06 Mar 2006 14:18:47 EST, Steve Grubb said:
> On Sunday 05 March 2006 19:38, Valdis.Kletnieks at 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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20060306/1c6bcacf/attachment.sig>