Message-ID: <20170905101545.1c6459a5@gandalf.local.home>
Date:   Tue, 5 Sep 2017 10:15:45 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        kasan-dev@...glegroups.com
Subject: Re: kmemleak not always catching stuff

On Mon, 4 Sep 2017 11:09:05 +0100
Catalin Marinas <catalin.marinas@....com> wrote:

> Hi Steve,
> 
> On Fri, Sep 01, 2017 at 06:33:11PM -0400, Steven Rostedt wrote:
> > Recently kmemleak discovered a bug in my code where an allocated
> > trampoline for a ftrace function tracer wasn't freed due to an exit
> > path. The thing is, kmemleak was able to catch this 100% when it was
> > triggered by one of my ftrace selftests that happen at bootup. But when
> > I trigger the issue from user space after bootup finished, it would not
> > catch it.  
> 
> Is this the create_filter() fix that went in recently?

No. I haven't pushed it. I just finished testing it and will include it
in my pull request to Linus. I just pushed it to my linux-next branch
(here's the link: http://lkml.kernel.org/r/20170905133217.883468521@goodmis.org)

> 
> > Now I was thinking that it may be due to the fact that the trampoline
> > is allocated with module_alloc(), and that has some magic kasan goo in
> > it. But when forcing the issue with adding the following code:
> > 
> > 	void **pblah;
> > 	void *blah;
> > 
> > 	pblah = kmalloc(sizeof(*pblah), GFP_KERNEL);	
> > 	blah = module_alloc(PAGE_SIZE);
> > 	*pblah = blah;
> > 	printk("allocated blah %p\n", blah);
> > 	kfree(pblah);
> > 
> > in a path that I could control, it would catch it only after doing it
> > several times. I was never able to have kmemleak catch the actual bug
> > from user space no matter how many times I triggered it.  
> 
> module_alloc() uses vmalloc_exec(), so it is tracked by kmemleak but you
> probably hit a false negative with the blah pointer lingering somewhere
> on some stack.

Hmm, could this also be what causes the miss of catching the lingering
ftrace trampoline?

> 
> >  # dmesg |grep kmemleak 
> > [   16.746832] kmemleak: Kernel memory leak detector initialized
> > [   16.746888] kmemleak: Automatic memory scanning thread started
> > 
> > And then I would do:
> > 
> >  # echo scan=on > /sys/kernel/debug/kmemleak  
> 
> scan=on is not necessary since this just enables the scanning thread
> (already started as per dmesg).

Yeah, but I found doing that appeared to catch things quicker when I
repeated the test.

> 
> >  [do the test]
> > 
> >  # echo scan > /sys/kernel/debug/kmemleak  
> 
> Some heuristics in kmemleak cause the first leak of an object not to be
> reported (too many false positives). You'd need to do "echo scan" at
> least twice after an allocation.

OK, is this documented somewhere?

> 
> I tried the same test code you have above triggered with an echo ... >
> /sys from user space. After the second scan it shows the leak, both with
> and without KASan.
> 
> > Most of the times it found nothing. Even when I switched the above from
> > module_alloc() to kmalloc().
> > 
> > Is this normal?  
> 
> In general, a leak would eventually appear after a few scans or in time
> when some memory location is overridden.
> 
> Yet another heuristics in kmemleak is to treat pointers at some offset
> inside an object as valid references (because of the container_of
> tricks). However, the downside is that the bigger the object, the
> greater chances of finding some random data that looks like a pointer.
> We could change this logic to require precise pointers above a certain
> size (e.g. PAGE_SIZE) where the use of container_of() is less likely.
> 
> Kmemleak doesn't have a way to inspect false negatives but if you are
> interested in digging further, I could add a "find=0x..." command to
> print all references to an object during scanning. I also need to find
> some time to implement a "stopscan" command which uses stop_machine()
> and skips the heuristics for reducing false positives.
> 

Without the patch in the link above, there's a memory leak with the
ftrace trampoline with the following commands:

Requires: CONFIG_FUNCTION_TRACER and CONFIG_SCHED_TRACER

 # cd /sys/kernel/debug/tracing
 # mkdir instances/foo
 # echo wakeup > instances/foo/current_tracer
 # echo 0 > /proc/sys/kernel/ftrace_enabled
 # echo nop > instances/foo/current_tracer
 # rmdir instances/foo

What the above does, is creates a new (allocated/non-static) buffer in
the instance directory. Then we enable the wakeup tracer which
enables function tracing and also creates a dynamic ftrace trampoline
for it. We disable function tracing for all tracers with the proc
sysctl ftrace_enabled set to zero. The nop removes the wakeup tracer
and unregisters its function tracing handler. This is where the leak
happens. The unregister path sees that function tracing is disabled and
exits out early, without releasing the trampoline.

To make sure nothing else may be accessing it, I even remove the trace
instance with the rmdir.

I tried the above over and over and kmemleak never catches it. The
attached patch is what I added to debug this to see that it was not
being freed. This patch can be added on top of the above commit, as it
reverts the fix.

Note, this is basically the same printks I used to debug what was
happening with the original triggering of kmemleak (which only caught
this on boot up, via the ftrace self tests).

-- Steve

View attachment "kmemleak-debug.patch" of type "text/x-patch" (4083 bytes)

Powered by blists - more mailing lists