[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Thu, Mar 02, 2006 at 02:39:42PM -0600, Dustin Kirkland wrote:
> 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?

The collected values qbytes, uid, gid, and mode represent the settings
that the user is requesting to write for the IPC object in an IPC_SET
operation, not the values of the current settings.  So in ipcperms()
you need to pass an invalid value for all four of those parameters.  I
believe 0 is a valid setting for all of them, so you'll need a
different value.

On that note, you may also want to change the name audit_ipc_perms()
to reflect the fact that you are no longer gathering only the
requested perm settings, but object labels as well.  E.g., audit_ipc()
is a more general name and would follow the other interfaces doing
similar things: audit_socketcall(), audit_sockaddr(), etc.

Amy


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]