Another slab size-32 leak 2.6.16-rc4-mm2

[Valdis.Kletnieks at vt.edu]

My system isn't leaking as badly after the first patch, but I still 
currently have about 174,000+ leaked size-32 from <ipcperms+0xf/0x91>
after about an hour's uptime.

Looks like if audit_ipc_context() is called from elsewhere in kernel/auditsc.c,
it's cleaned up after.  However, the call from ipc/util.c in ipcperms() doesn't
seem to get cleaned up after (and, in fact, it isn't clear why it's even called
there, at least to me...)

diff --git a/ipc/util.c b/ipc/util.c
index 8626219..e37e1e9 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -27,6 +27,7 @@
 #include <linux/workqueue.h>
 #include <linux/seq_file.h>
 #include <linux/proc_fs.h>
+#include <linux/audit.h>

 #include <asm/unistd.h>

@@ -468,6 +469,7 @@ int ipcperms (struct kern_ipc_perm *ipcp
 {      /* flag will most probably be 0 or S_...UGO from <linux/stat.h> */
        int requested_mode, granted_mode;

+       audit_ipc_context(ipcp);
        requested_mode = (flag >> 6) | (flag >> 3) | flag;
        granted_mode = ipcp->mode;
        if (current->euid == ipcp->cuid || current->euid == ipcp->uid)

Looks like the source of my problem...
-------------- 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/20060224/57562447/attachment.sig>