Messages in this thread | | | Date | Fri, 8 Sep 2017 14:34:48 -0400 | From | Steven Rostedt <> | Subject | Re: kmemleak not always catching stuff |
| |
On Fri, 8 Sep 2017 18:45:20 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote:
> > Hmm, could this also be what causes the miss of catching the lingering > > ftrace trampoline? > > Not sure (not without some additional support in kmemleak to help track > down the source of false negatives; I'm on a long flight to LA next > week, maybe I manage to hack something up ;)).
I'll be there too. We can talk more about this in person ;-)
I'll probably be at the VMware booth a bit, as one of our team had a family emergency and had to cancel.
> > BTW, I had a quick look at the trace_selftest_ops() function (without > pretending I understand the ftrace code) and there is one case where
I personally just pretend I understand it.
> this function can exit without freeing dyn_ops. Is this intentional? > > diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c > index cb917cebae29..b17ec642793b 100644 > --- a/kernel/trace/trace_selftest.c > +++ b/kernel/trace/trace_selftest.c > @@ -273,7 +273,7 @@ static int trace_selftest_ops(struct trace_array *tr, int cnt) > goto out_free; > if (cnt > 1) { > if (trace_selftest_test_global_cnt == 0) > - goto out; > + goto out_free; > } > if (trace_selftest_test_dyn_cnt == 0) > goto out_free; >
You mean something like this:
http://lkml.kernel.org/r/20170905133217.770389331@goodmis.org
:-)
> > > > 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. > > Are the ftrace_ops allocated dynamically in this case (and freed when > unregistered)? Otherwise, you may have an ops->trampoline still around > that kmemleak finds. >
The ftrace_ops is allocated when the instance is created, and freed when the instance is removed:
instance_mkdir() { init_tracer_fs() { ftrace_create_function_files() { allocate_ftrace_ops() { ops = kzalloc(); tr->ops = ops; } } } }
instance_rmdir() { ftrace_destroy_function_files() { kfree(tr->ops); } }
-- Steve
| |