Re: Another slab size-32 leak 2.6.16-rc4-mm2

On Wed, 2006-03-01 at 13:52 -0500, Amy Griffis wrote: Thank you, this is the analysis that I was looking for. I'm in-lining a simple patch that solves memory leak and collects the required information. Rather than calling audit_ipc_context() which allocates memory and returns a char * which was being lost, ipcperms() instead calls audit_ipc_perms(), which wraps audit_ipc_context() thereby storing the context in an auxiliary IPC audit record. This happens each and every time ipcperms() is called. Note that the first argument of audit_ipc_perms() is qbytes, which I've zero'd out inside of ipcperms() as that information is not available within the scope of the ipcperms() function. Is that ok? One more note... I'm attaching a short blip of test code that runs through each of the msg* calls Amy mentions above. The code doesn't do anything useful with IPC msg's, but I used it to verify that audit messages are generated and subj/obj labels are collected. Thanks. :-Dustin diff --git a/ipc/util.c b/ipc/util.c index e37e1e9..07fff36 100644 --- a/ipc/util.c +++ b/ipc/util.c @@ -469,7 +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); + audit_ipc_perms(0, ipcp->uid, ipcp->gid, ipcp->mode, ipcp); requested_mode = (flag >> 6) | (flag >> 3) | flag; granted_mode = ipcp->mode; if (current->euid == ipcp->cuid || current->euid == ipcp->uid)