[OpenAFS-devel] vmalloc memory leak in 1.3.84/85?

[chas williams - CONTRACTOR]

In message <20050727163226.GH8061@poobah.Stanford.EDU>,Miles Davis writes:
>> I think I may have come across a memory leak in 1.3.84/1.3.85. It's 
>Found it. A combination of long lived (24h) tokens and frequent, short 
>lived sessions (imap, pop) filled up the vmalloc area. The odd thing is 
>that the afs client doesn't seem to free up vmalloc space when tokens 
>are destroyed (say, through pam_krb5 or unlog). The memory remains 
>allocated until some time after the token expires. Is that expected?

i would hazard a guess that something is wrong with the groups
manipulation code.  this was the only big change from 2.4 -> 2.6 for
the PAG code.  generally speaking if afs itself had a memory leak on
linux you would probably see hash_bucket_stat() gripe about the the hash
buckets getting too long.

i see that afs_getgroups() increments the reference on the current
group_info and returns it.  setpag() calls this function, but doesnt
seem to drop the reference returned by afs_getgroups().  perhaps
you could try this patch.  i wouldnt hold my breath though.

Index: src/afs/LINUX/osi_groups.c
===================================================================
RCS file: /cvs/openafs/src/afs/LINUX/osi_groups.c,v
retrieving revision 1.27
diff -u -u -r1.27 osi_groups.c
--- src/afs/LINUX/osi_groups.c	14 Jan 2005 01:34:54 -0000	1.27
+++ src/afs/LINUX/osi_groups.c	27 Jul 2005 18:10:27 -0000
@@ -172,6 +172,8 @@
     
     for (i = 0; i < group_info->ngroups; ++i)
       GROUP_AT(tmp, i + need_space) = GROUP_AT(group_info, i);
+
+    put_group_info(group_info);
     group_info = tmp;
 
     *newpag = (pagvalue == -1 ? genpag() : pagvalue);