Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps

[Steven Rostedt]

On Fri, 6 Oct 2017 23:41:25 -0700
"Joel Fernandes (Google)" <joel.opensrc@xxxxxxxxx> wrote:

> Hi Steve,
> 
> On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > From: "Steven Rostedt (VMware)" <rostedt@xxxxxxxxxxx>
> >
> > The ftrace_mod_map is a descriptor to save module init function names in
> > case they were traced, and the trace output needs to reference the function
> > name from the function address. But after the function is unloaded, it
> > the maps should be freed, as the rest of the function names are as well.  
> 
> Just checking for my understanding of this patch - wouldn't this also
> mean that if there were any look ups of the init functions that may be
> needed at trace output time, then those look ups wont be possible any
> more after module is unloaded?

Yes. That's true for all functions in the module. When a module is
unloaded, all references to it in kallsyms is also freed. Try it on a
current kernel. Trace a function in a module, then unload that module.
The trace data will just show the ip hex address of the module function
after that.

> 
> I guess having a reference somehow on the ftrace_mod_map descriptor if
> there are any entries in the trace buffer that need it can help
> prevent that but it could be too expensive for not much return since
> most likely the user wouldn't unload modules before trace collection
> in normal usage.

Right, I have thought about this, and I haven't come up with an
inexpensive way to do this. As this has been the default operation of
all module functions, and I haven't heard much complaining about it (I
think I may have had a single complaint), I didn't put too much effort
into it.

I need to look at the approach that Jessica sent me. Perhaps there's
ways to have all module function names be saved by a trace. But mapping
which trace buffer has these names may be difficult.

-- Steve