linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Enabling function trace on call during module init
@ 2013-09-07  3:55 Venkat Subbiah
  2013-09-08  0:48 ` Steven Rostedt
  0 siblings, 1 reply; 6+ messages in thread
From: Venkat Subbiah @ 2013-09-07  3:55 UTC (permalink / raw)
  To: linux-rt-users

Hello,

Would like to be able to trace function calls executed during the
initialization of the kernel module. Is that possible?


Thanks,
Venkat

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enabling function trace on call during module init
  2013-09-07  3:55 Enabling function trace on call during module init Venkat Subbiah
@ 2013-09-08  0:48 ` Steven Rostedt
  2013-09-14  3:59   ` Venkat Subbiah
  2013-10-11 10:15   ` Sebastian Andrzej Siewior
  0 siblings, 2 replies; 6+ messages in thread
From: Steven Rostedt @ 2013-09-08  0:48 UTC (permalink / raw)
  To: Venkat Subbiah; +Cc: linux-rt-users

On Fri, 6 Sep 2013 20:55:54 -0700
Venkat Subbiah <venkat.mlist@gmail.com> wrote:

> Hello,
> 
> Would like to be able to trace function calls executed during the
> initialization of the kernel module. Is that possible?
> 

Well, yes and no, and it depends ;-)


You wont be able to trace any function that is annotated with "__init",
or even "__exit". That's because the init section does not have a
standard way of cleaning them up (for boot, modules are different, but
are still affected by it).

As ftrace modifies code, and it modifies locations of functions, it can
not safely modify code that suddenly disappeared without it knowing it,
otherwise you may end up with broken NIC cards.

Note, I do plan on adding code that will fix this in the future, but
today, unfortunately, we don't have it.

For functions that are not marked by __init, they will be traced. If
you trace all functions, they will be traced when the module is loaded.
This may not help you either, because by tracing all functions, you
will probably lose the data you want due to overflow of the buffers.

This too may change in the future, but currently we don't have it :-/

-- Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enabling function trace on call during module init
  2013-09-08  0:48 ` Steven Rostedt
@ 2013-09-14  3:59   ` Venkat Subbiah
  2013-10-11 10:15   ` Sebastian Andrzej Siewior
  1 sibling, 0 replies; 6+ messages in thread
From: Venkat Subbiah @ 2013-09-14  3:59 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: linux-rt-users

Steven,

Thanks a lot for the info.

-Venkat

On Sat, Sep 7, 2013 at 5:48 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 6 Sep 2013 20:55:54 -0700
> Venkat Subbiah <venkat.mlist@gmail.com> wrote:
>
>> Hello,
>>
>> Would like to be able to trace function calls executed during the
>> initialization of the kernel module. Is that possible?
>>
>
> Well, yes and no, and it depends ;-)
>
>
> You wont be able to trace any function that is annotated with "__init",
> or even "__exit". That's because the init section does not have a
> standard way of cleaning them up (for boot, modules are different, but
> are still affected by it).
>
> As ftrace modifies code, and it modifies locations of functions, it can
> not safely modify code that suddenly disappeared without it knowing it,
> otherwise you may end up with broken NIC cards.
>
> Note, I do plan on adding code that will fix this in the future, but
> today, unfortunately, we don't have it.
>
> For functions that are not marked by __init, they will be traced. If
> you trace all functions, they will be traced when the module is loaded.
> This may not help you either, because by tracing all functions, you
> will probably lose the data you want due to overflow of the buffers.
>
> This too may change in the future, but currently we don't have it :-/
>
> -- Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enabling function trace on call during module init
  2013-09-08  0:48 ` Steven Rostedt
  2013-09-14  3:59   ` Venkat Subbiah
@ 2013-10-11 10:15   ` Sebastian Andrzej Siewior
  2013-10-11 12:35     ` Steven Rostedt
  1 sibling, 1 reply; 6+ messages in thread
From: Sebastian Andrzej Siewior @ 2013-10-11 10:15 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Venkat Subbiah, linux-rt-users

* Steven Rostedt | 2013-09-07 20:48:11 [-0400]:

>You wont be able to trace any function that is annotated with "__init",
>or even "__exit". That's because the init section does not have a
>standard way of cleaning them up (for boot, modules are different, but
>are still affected by it).

Is this even required / wanted? Usually the module just hooks itself
into subsystem like pci_register_driver() and is usually not
interresting. The interresting part starts from ->probe() (I think) and
this is captured, right?

>As ftrace modifies code, and it modifies locations of functions, it can
>not safely modify code that suddenly disappeared without it knowing it,
>otherwise you may end up with broken NIC cards.
Hmmm. This sounds like you know what you are talking about :)

>-- Steve

Sebastian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enabling function trace on call during module init
  2013-10-11 10:15   ` Sebastian Andrzej Siewior
@ 2013-10-11 12:35     ` Steven Rostedt
  2013-10-11 13:02       ` Sebastian Andrzej Siewior
  0 siblings, 1 reply; 6+ messages in thread
From: Steven Rostedt @ 2013-10-11 12:35 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior; +Cc: Venkat Subbiah, linux-rt-users

On Fri, 11 Oct 2013 12:15:31 +0200
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> * Steven Rostedt | 2013-09-07 20:48:11 [-0400]:
> 
> >You wont be able to trace any function that is annotated with "__init",
> >or even "__exit". That's because the init section does not have a
> >standard way of cleaning them up (for boot, modules are different, but
> >are still affected by it).
> 
> Is this even required / wanted? Usually the module just hooks itself
> into subsystem like pci_register_driver() and is usually not
> interresting. The interresting part starts from ->probe() (I think) and
> this is captured, right?

Only if the ->probe() is not marked __init

There's a white list of sections that the function tracer traces. See
is_mcounted_section_name() in scripts/recordmcount.c.

-- Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Enabling function trace on call during module init
  2013-10-11 12:35     ` Steven Rostedt
@ 2013-10-11 13:02       ` Sebastian Andrzej Siewior
  0 siblings, 0 replies; 6+ messages in thread
From: Sebastian Andrzej Siewior @ 2013-10-11 13:02 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Venkat Subbiah, linux-rt-users

On 10/11/2013 02:35 PM, Steven Rostedt wrote:
>> Is this even required / wanted? Usually the module just hooks itself
>> into subsystem like pci_register_driver() and is usually not
>> interresting. The interresting part starts from ->probe() (I think) and
>> this is captured, right?
> 
> Only if the ->probe() is not marked __init

Yes, and this shouldn't be the case due to hotplug which is the
default. So unless you want trace pci_register_driver() & friends we
are good I think :)

> -- Steve
> 

Sebastian

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-10-11 13:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-07  3:55 Enabling function trace on call during module init Venkat Subbiah
2013-09-08  0:48 ` Steven Rostedt
2013-09-14  3:59   ` Venkat Subbiah
2013-10-11 10:15   ` Sebastian Andrzej Siewior
2013-10-11 12:35     ` Steven Rostedt
2013-10-11 13:02       ` Sebastian Andrzej Siewior

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).