Messages in this thread |  | | Date | Sat, 7 Oct 2017 09:32:21 -0400 | From | Steven Rostedt <> | Subject | Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod_maps |
| |
On Fri, 6 Oct 2017 23:41:25 -0700 "Joel Fernandes (Google)" <joel.opensrc@gmail.com> wrote:
> Hi Steve, > > On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt <rostedt@goodmis.org> wrote: > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org> > > > > 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
|  |