linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Question about 'for_each_kernel_tracepoint(...)' function
@ 2022-10-20  9:32 richard clark
  2022-10-20 15:14 ` Steven Rostedt
  0 siblings, 1 reply; 7+ messages in thread
From: richard clark @ 2022-10-20  9:32 UTC (permalink / raw)
  To: rostedt, bristot; +Cc: linux-trace-devel, linux-kernel

Hi,
Can this function only find the trace points defined in the kernel
image? I want to define a trace event in my kernel module A, then B
module to register a probe callback function for that event TP in A. I
want to kick off a timer in A and call the traced function
periodically, thus I can monitor the events happening in A from B.

Can I do that, is it possible?

Richard

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

* Re: Question about 'for_each_kernel_tracepoint(...)' function
  2022-10-20  9:32 Question about 'for_each_kernel_tracepoint(...)' function richard clark
@ 2022-10-20 15:14 ` Steven Rostedt
  2022-10-21  1:43   ` richard clark
  0 siblings, 1 reply; 7+ messages in thread
From: Steven Rostedt @ 2022-10-20 15:14 UTC (permalink / raw)
  To: richard clark; +Cc: bristot, linux-trace-devel, linux-kernel

On Thu, 20 Oct 2022 17:32:57 +0800
richard clark <richard.xnu.clark@gmail.com> wrote:

> Hi,
> Can this function only find the trace points defined in the kernel

It should find all tracepoints.

> image? I want to define a trace event in my kernel module A, then B
> module to register a probe callback function for that event TP in A. I
> want to kick off a timer in A and call the traced function
> periodically, thus I can monitor the events happening in A from B.

You could also export the tracepoint from A and reference it directly in B.

> 
> Can I do that, is it possible?
> 

Try it and find out. Why ask?

-- Steve

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

* Re: Question about 'for_each_kernel_tracepoint(...)' function
  2022-10-20 15:14 ` Steven Rostedt
@ 2022-10-21  1:43   ` richard clark
  2022-10-21  2:12     ` Steven Rostedt
  0 siblings, 1 reply; 7+ messages in thread
From: richard clark @ 2022-10-21  1:43 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: bristot, linux-trace-devel, linux-kernel

On Thu, Oct 20, 2022 at 11:14 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 20 Oct 2022 17:32:57 +0800
> richard clark <richard.xnu.clark@gmail.com> wrote:
>
> > Hi,
> > Can this function only find the trace points defined in the kernel
>
> It should find all tracepoints.
I defined an event trace point in module B(in the header file):
...
#define TRACE_SYSTEM    cus_tp
...
TRACE_EVENT(function_event_a,
        /* all the data struct parameter is in form of pointer instead
of object */
        TP_PROTO(enum event ev),
        TP_ARGS(ev),
        ...
);

After the module B inserted, the output is:

root@robotics:/sys/kernel/debug/tracing# cat available_events | grep func
cus_tp:function_event_a

Then I inserted module A with below code snippet:

void fc(struct tracepoint *ktp, void *priv)
{
    pr_info("events: %s\n", ktp->name);
}

static int module_A_init(void)
{
    for_each_kernel_tracepoint(fc, NULL);
    return 0;
}

Then I insert the module A into the system with module B is inserted,
the dmesg shows:

root@ robotics:/home/robotics/evt-tp# dmesg | grep func
[149421.718576] events: call_function_entry
[149421.718578] events: call_function_exit
[149421.718579] events: call_function_single_entry
[149421.718581] events: call_function_single_exit

So Steve you can see that the 'for_each_kernel_tracepoint' doesn't
find the event tp defined in module B, but that tp indeed shows in
/sys/kernel/debug/tracing/available_events.

Any comments about that?

>
> > image? I want to define a trace event in my kernel module A, then B
> > module to register a probe callback function for that event TP in A. I
> > want to kick off a timer in A and call the traced function
> > periodically, thus I can monitor the events happening in A from B.
>
> You could also export the tracepoint from A and reference it directly in B.
>
> >
> > Can I do that, is it possible?
> >
>
> Try it and find out. Why ask?

Ah, as you can see that I did it, but the result is not what I
expected :-). Help?

Richard

>
> -- Steve

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

* Re: Question about 'for_each_kernel_tracepoint(...)' function
  2022-10-21  1:43   ` richard clark
@ 2022-10-21  2:12     ` Steven Rostedt
  2022-10-21  3:51       ` richard clark
  0 siblings, 1 reply; 7+ messages in thread
From: Steven Rostedt @ 2022-10-21  2:12 UTC (permalink / raw)
  To: richard clark; +Cc: bristot, linux-trace-devel, linux-kernel

On Fri, 21 Oct 2022 09:43:14 +0800
richard clark <richard.xnu.clark@gmail.com> wrote:


> Ah, as you can see that I did it, but the result is not what I
> expected :-). Help?

Looking at the code, I see it does indeed only look at builtin tracepoints.

But if you want one module to have access to the tracepoints of another,
then you can have the first one export it.

EXPORT_SYMBOL_TRACEPOINT_GPL(function_event_a);

And then module b should have access to it.

-- Steve

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

* Re: Question about 'for_each_kernel_tracepoint(...)' function
  2022-10-21  2:12     ` Steven Rostedt
@ 2022-10-21  3:51       ` richard clark
  2022-10-21 12:32         ` Steven Rostedt
  0 siblings, 1 reply; 7+ messages in thread
From: richard clark @ 2022-10-21  3:51 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: bristot, linux-trace-devel, linux-kernel

On Fri, Oct 21, 2022 at 10:12 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 21 Oct 2022 09:43:14 +0800
> richard clark <richard.xnu.clark@gmail.com> wrote:
>
>
> > Ah, as you can see that I did it, but the result is not what I
> > expected :-). Help?
>
> Looking at the code, I see it does indeed only look at builtin tracepoints.

What the logic behind is not to implement a function like
'for_each_tracepoints' instead of 'for_each_kernel_tracepoint' to find
all the TPs defined by both builtin kernel and external kernel
modules, just like we can find all the kernel symbols and exported
symbols from external module?

>
> But if you want one module to have access to the tracepoints of another,
> then you can have the first one export it.
>
> EXPORT_SYMBOL_TRACEPOINT_GPL(function_event_a);
>
> And then module b should have access to it.
>
Yes, but module b needs to register a new probe call back function for
the new TPs defined by module a in my case, so first it needs to find
the TPs defined by module a. Any comments?

> -- Steve

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

* Re: Question about 'for_each_kernel_tracepoint(...)' function
  2022-10-21  3:51       ` richard clark
@ 2022-10-21 12:32         ` Steven Rostedt
  2022-10-22  2:55           ` richard clark
  0 siblings, 1 reply; 7+ messages in thread
From: Steven Rostedt @ 2022-10-21 12:32 UTC (permalink / raw)
  To: richard clark; +Cc: bristot, linux-trace-devel, linux-kernel

On Fri, 21 Oct 2022 11:51:20 +0800
richard clark <richard.xnu.clark@gmail.com> wrote:

> On Fri, Oct 21, 2022 at 10:12 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Fri, 21 Oct 2022 09:43:14 +0800
> > richard clark <richard.xnu.clark@gmail.com> wrote:
> >
> >  
> > > Ah, as you can see that I did it, but the result is not what I
> > > expected :-). Help?  
> >
> > Looking at the code, I see it does indeed only look at builtin tracepoints.  
> 
> What the logic behind is not to implement a function like
> 'for_each_tracepoints' instead of 'for_each_kernel_tracepoint' to find
> all the TPs defined by both builtin kernel and external kernel
> modules, just like we can find all the kernel symbols and exported
> symbols from external module?

Why? It's not needed upstream. If you push your code upstream and it's
something to get accepted, then we can think about adding that.

> 
> >
> > But if you want one module to have access to the tracepoints of another,
> > then you can have the first one export it.
> >
> > EXPORT_SYMBOL_TRACEPOINT_GPL(function_event_a);
> >
> > And then module b should have access to it.
> >  
> Yes, but module b needs to register a new probe call back function for
> the new TPs defined by module a in my case, so first it needs to find
> the TPs defined by module a. Any comments?

No, because I have no idea what you are doing or why you need this.

-- Steve

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

* Re: Question about 'for_each_kernel_tracepoint(...)' function
  2022-10-21 12:32         ` Steven Rostedt
@ 2022-10-22  2:55           ` richard clark
  0 siblings, 0 replies; 7+ messages in thread
From: richard clark @ 2022-10-22  2:55 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: bristot, linux-trace-devel, linux-kernel

On Fri, Oct 21, 2022 at 8:32 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 21 Oct 2022 11:51:20 +0800
> richard clark <richard.xnu.clark@gmail.com> wrote:
>
> > On Fri, Oct 21, 2022 at 10:12 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
> > > On Fri, 21 Oct 2022 09:43:14 +0800
> > > richard clark <richard.xnu.clark@gmail.com> wrote:
> > >
> > >
> > > > Ah, as you can see that I did it, but the result is not what I
> > > > expected :-). Help?
> > >
> > > Looking at the code, I see it does indeed only look at builtin tracepoints.
> >
> > What the logic behind is not to implement a function like
> > 'for_each_tracepoints' instead of 'for_each_kernel_tracepoint' to find
> > all the TPs defined by both builtin kernel and external kernel
> > modules, just like we can find all the kernel symbols and exported
> > symbols from external module?
>
> Why? It's not needed upstream. If you push your code upstream and it's
> something to get accepted, then we can think about adding that.
>
> >
> > >
> > > But if you want one module to have access to the tracepoints of another,
> > > then you can have the first one export it.
> > >
> > > EXPORT_SYMBOL_TRACEPOINT_GPL(function_event_a);
> > >
> > > And then module b should have access to it.
> > >
> > Yes, but module b needs to register a new probe call back function for
> > the new TPs defined by module a in my case, so first it needs to find
> > the TPs defined by module a. Any comments?
>
> No, because I have no idea what you are doing or why you need this.

I've noticed that we have a Runtime Verification module merged into
the mainline and very interesting, so I am trying to provide a monitor
for my events in module A,  which means we need to register some new
probe call back functions for the TPs defined in the external kernel
modules. OK, I am writing this email just to confirm, maybe I need to
think about if I can add the external TPs into the
'for_each_kernel_tracepoint(...)' function...

Thanks!

>
> -- Steve

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

end of thread, other threads:[~2022-10-22  2:55 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-20  9:32 Question about 'for_each_kernel_tracepoint(...)' function richard clark
2022-10-20 15:14 ` Steven Rostedt
2022-10-21  1:43   ` richard clark
2022-10-21  2:12     ` Steven Rostedt
2022-10-21  3:51       ` richard clark
2022-10-21 12:32         ` Steven Rostedt
2022-10-22  2:55           ` richard clark

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).