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

[Jeffrey Hutzelman]

On Tuesday, October 25, 2005 06:10:51 PM +0200 Peter Somogyi 
<psomogyi@gamax.hu> wrote:

> I've looked into the libafs source, and found the root cause of our
> problem: afs_pioctl.c, DECL_PIOCTL(PUnlog):
> ...
># ifdef UKERNEL
> 	    /* set the expire times to 0, causes
> 	     * afs_GCUserData to remove this entry
> 	     */
> 	    tu->ct.EndTimestamp = 0;
> 	    tu->tokenTime = 0;
># endif /* UKERNEL */

GCUserData will still remove the entry (and destroy the connections) 
without that code, it just won't do so until some time after the tokens 
expire.  I'm not sure why someone thought it was important to get them 
right away on the next pass in the UKERNEL case.  I agree that including 
those operations will make unlog'd PAG's go away faster, but at the expense 
of some churning in the cases where people unlog and then immediately get 
new tokens.  I don't know if there might be other negative effects.


> - is our "km_afs" rpm wrong (km_afs-1.4-rc4 - generated based upon our
> special openafs.spec) that it doesn't define UKERNEL, or our openafs.spec
> is wrong that it doesn't define UKERNEL?

Neither.  It's not supposed to be defined.

> - why the above code part depends on UKERNEL flag?

Presumably someone thought it was really important to nuke the connections 
on the next pass in the UKERNEL case.


> - what does UKERNEL means really? What effect can I have if I turn it on
> somehow?

It's define when building the user-mode cache manager library.  It is never 
defined when building kernel modules.  If you turn it on, you will get the 
effect that your module will break, if it compiles at all.