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]

Message-ID: <CAPcyv4gHHPdCYPzLeNzX0KMoNrOf8H0N5PBiWam0wF+WhV-Jpg@mail.gmail.com>
Date:   Tue, 20 Apr 2021 12:54:39 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Steven Rostedt <rostedt@...dmis.org>
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 Tue, Apr 20, 2021 at 5:55 AM Steven Rostedt <rostedt@...dmis.org> wrote:
[..]
> > > 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.
> >
> > Ah, thanks for the pointer. So if I wanted to convert a kernel command like:
> >
> > libnvdimm.dyndbg
> >
> > ...it would be something like:
> >
> > ftrace=function ftrace_filter=:mod:libnvdimm
>
> Hmm, that may not work, but if it doesn't, it would be trivial to add it.
>
> >
> > ...and then "cat /sys/kernel/tracing/trace" instead of "dmesg" to
> > retrieve... assuming only "got here" style debug was being attempted.
> >
> > > To do something similar for tracepoints, I think we still need to add it as
> > > a module parameter.
> >
> > The dev_dbg() filter language is attractive, it's too bad
>
> Not sure what you mean by that. What filter language. Tracepoints do have a
> pretty good filtering too.

I'm trying to replicate dev_dbg() usability with tracing. So, when
people say "don't use dev_dbg() for that" that tracing can reliably
replace everything that dev_dbg() was offering. What I think that
looks like is the ability to turn on function tracing by a function
name glob in addition to any tracepoints in those same functions all
from the kernel boot command line, or a module parameter.

> > trace_printk() has such a high runtime cost as combining dynamic-debug
> > and tracing would seem to be a panacea.
>
> trace_printk() has a high runtime cost? Besides that it's not allowed on
> production code (see nasty banner), it is made to be extremely fast.
> Although, it does do sprintf() work.

I was referring to the banner. dev_dbg() does not have that production
code restriction.

> Would adding automatic module parameters be an issue? That is, you can add
> in the insmod command line a parameter that will enable tracepoints. We
> could have a way to even see them from the modinfo. I think I had that
> working once, and it wasn't really that hard to do.

Yeah, that's what you seemed to have working at the beginning of this thread:

https://lore.kernel.org/lkml/1299622684.20306.77.camel@gandalf.stny.rr.com/