linux-kernel - Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 19 Apr 2021 18:11:11 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Williams, Dan J" <dan.j.williams@...el.com>
Cc:     "fweisbec@...il.com" <fweisbec@...il.com>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...e.hu" <mingo@...e.hu>,
        "chris@...is-wilson.co.uk" <chris@...is-wilson.co.uk>,
        "yuanhan.liu@...ux.intel.com" <yuanhan.liu@...ux.intel.com>,
        "Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>
Subject: Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters

On Mon, 19 Apr 2021 21:54:13 +0000
"Williams, Dan J" <dan.j.williams@...el.com> wrote:

> [ drop Rusty, add Jessica and Emmanuel ]

Probably could have kept Jessica on as she's the module maintainer.

> 
> On Wed, 2013-08-14 at 23:32 -0400, Steven Rostedt wrote:
> > On Thu, 15 Aug 2013 11:32:10 +0930

Wow, this is coming back from the dead! No thread rests in peace!

> > Rusty Russell <rusty@...tcorp.com.au> wrote:
> >   
> > > Steven Rostedt <rostedt@...dmis.org> writes:  
> > > > But the thing about this that bothers me is that there's no way
> > > > to say,
> > > > "Enable all tracepoints in this module on load". I would like a
> > > > way to
> > > > do that, but I don't know of a way to do that without modifying
> > > > the
> > > > module code. Have any ideas? Basically, I would love to have:
> > > > 
> > > > insmod foo tracepoints=all
> > > > 
> > > > or something and have all tracepoints enabled.  
> > > 
> > > "without modifying the module code"?  Why?  The code isn't that
> > > scary,
> > > and this seems useful.  
> > 
> > I'm not afraid of the code, I'm afraid of you ;-) I hear you have
> > killer puppies.
> > 
> > 
> > OK, then when I get some time, I may cook something up.


"when I get some time" HAHAHAHAHAHAH!!!!  That was what? 8 years ago!

> > 
> > Thanks,
> > 
> > -- Steve  
> 
> Revive an old thread...

I'll say!

> 
> Steven, did you ever end up with a solution to the "enable tracing at
> module load" problem?

For tracepoints, no. For function tracing, yes!

> 
> I see some people getting admonished to use ftrace over dev_dbg() [1],
> but one of the features that keeps dev_dbg() proliferating is its
> generic "$mod_name.dyndbg=" module parameter support for selective
> debug enabling at boot / module-load.
> 
> It would be useful to be able to do
> /sys/kernel/debug/dynamic_debug/control enabling for tracepoints, but
> also module::function_name patterns for "got here" style debugging. I'd
> be happy to help with this, but wanted to understand where you left
> things.
> 
> [1]: https://lore.kernel.org/linux-wireless/YHRFy3aq%2FgB7Vde6@kroah.com/

I don't think I did anything with trace events, I'll have to dig deeper.
But today you have this:

 # cd /sys/kernel/tracing

 # rmmod bridge

 # echo ':mod:bridge' > set_ftrace_filter 

 # cat set_ftrace_filter
:mod:bridge

 # echo function > current_tracer

 # cat trace
# tracer: function
#
# entries-in-buffer/entries-written: 0/0   #P:8
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |

 # modprobe bridge

 # cat set_ftrace_filter
br_switchdev_event [bridge]
br_device_event [bridge]
br_net_exit [bridge]
br_boolopt_get [bridge]
br_boolopt_multi_get [bridge]
br_opt_toggle [bridge]
br_boolopt_toggle [bridge]
br_boolopt_multi_toggle [bridge]
br_dev_set_multicast_list [bridge]
br_get_link_ksettings [bridge]
[..]

 # cat trace
# tracer: function
#
# entries-in-buffer/entries-written: 10/10   #P:8
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |
        modprobe-2364    [006] .... 12929.869510: br_init <-do_one_initcall
        modprobe-2364    [006] .... 12929.869513: br_fdb_init <-br_init
        modprobe-2364    [006] .... 12929.869522: br_device_event <-call_netdevice_register_net_notifiers
        modprobe-2364    [006] .... 12929.869522: br_device_event <-call_netdevice_register_net_notifiers
        modprobe-2364    [006] .... 12929.869522: br_device_event <-call_netdevice_register_net_notifiers
        modprobe-2364    [006] .... 12929.869522: br_device_event <-call_netdevice_register_net_notifiers
        modprobe-2364    [006] .... 12929.869523: br_device_event <-call_netdevice_register_net_notifiers
        modprobe-2364    [006] .... 12929.869523: br_device_event <-call_netdevice_register_net_notifiers
        modprobe-2364    [006] .... 12929.869524: br_netlink_init <-br_init
        modprobe-2364    [006] .... 12929.869524: br_mdb_init <-br_netlink_init


So yes, function tracing now allows setting a filter to trace only the
functions for a given module, and if that module is not yet loaded, it
stores the filter until it is.

To do something similar for tracepoints, I think we still need to add it as
a module parameter.

-- Steve