Re: Possible memory leaks in proc_sysctl.c

[Catalin Marinas]

On Wed, Apr 18, 2012 at 04:44:27PM +0100, Eric W. Biederman wrote:
> Catalin Marinas <catalin.marinas@xxxxxxx> writes:
> > On Wed, Apr 18, 2012 at 03:52:58PM +0100, Eric W. Biederman wrote:
> >> So simply saying kmemleak shut up this is deliberate in these few cases
> >> where we don't intend to unregister the structure and have a deliberate
> >> leak seems the clean and maintainable way to go.
> >
> > OK, I got it now, sounds fair. But please add a comment to the
> > kmemleak_not_leak() annotations so that others know it's a deliberate
> > leak (rather than a false positive).
> >
> > Also the patch should include the linux/kmemleak.h file for the
> > kmemleak_not_leak() prototype as header changes in the future may cause
> > problems (I think the one you posted did not include it).
> 
> I will take a look when I merge the patch.
> 
> Would something like kmemleak_ignore() be better?  What I want is
> kmemleak_this_is_a_deliberate_leak_so_shut_up(), but the API doesn't
> seem to exactly include that function.  I'm not certain what the proper
> name is as I haven't worked much with kmemleak.

kmemleak_ignore() can be used as long as the object does not reference
other objects since it won't even be scanned. In this case, it only
hides the returned header object but there seem to be two more objects
allocated during the register_sysctl_table() call and referenced from
the returned header.

kmemleak_not_leak() would do the right thing here, though it was meant
for annotating false positives rather than real leaks. I think a comment
on the calling site would be enough.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/