Re: ftrace: Save module init functions kallsyms symbols for tracing

[Steven Rostedt]

On Mon, 9 Oct 2017 15:51:00 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:


> > Using the snd_seq example from patch 03, I get the same human-readable trace:
> > 
> > # tracer: function
> > #
> > #                              _-----=> irqs-off
> > #                             / _----=> need-resched
> > #                            | / _---=> hardirq/softirq
> > #                            || / _--=> preempt-depth
> > #                            ||| /     delay
> > #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> > #              | |       |   ||||       |         |
> >         modprobe-12748 [005] ....   138.964923: alsa_seq_init <-do_one_initcall
> >         modprobe-12748 [005] ....   138.964924: client_init_data <-alsa_seq_init
> >         modprobe-12748 [005] ....   138.964924: snd_sequencer_memory_init <-alsa_seq_init
> >         modprobe-12748 [005] ....   138.964924: snd_seq_queues_init <-alsa_seq_init
> >         modprobe-12748 [005] ....   138.964924: snd_sequencer_device_init <-alsa_seq_init
> >         modprobe-12748 [005] ....   138.964956: snd_seq_info_init <-alsa_seq_init
> >         modprobe-12748 [005] ....   138.964956: create_info_entry <-snd_seq_info_init
> >         modprobe-12748 [005] ....   138.964958: create_info_entry <-snd_seq_info_init
> >         modprobe-12748 [005] ....   138.964959: create_info_entry <-snd_seq_info_init
> >         modprobe-12748 [005] ....   138.964960: snd_seq_system_client_init <-alsa_seq_init
> >         modprobe-12748 [005] ....   138.964960: snd_seq_create_kernel_client <-snd_seq_system_client_init
> > 
> > In addition, the module init functions appear in /proc/kallsyms as
> > well. Thoughts? Would saving init symbol information in the module
> > symtab be sufficient for ftrace?

Hi Jessica,

Are you going to have time to work on this more?

Should we allow multiple init addresses to appear, or should there be
some check to see if they already exist, and remove the older one?

Ideally, I could have a way to know if a module init function was
traced and its address was stored in a ring buffer, and keep the init
mapping around and used for that buffer, and free it when the buffer
is cleared, and there's no other buffers that have a reference to it.
But I need to find a low overhead way to account for this.

Personally, I would rather have the mappings saved in the symbol tables
in the module code.

If we can come up with a better module way, I'll convert to that. But
as I want to get this code upstream by 4.15, I'm going to continue with
what I have.

Thoughts?

-- Steve