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:	Tue, 08 Mar 2011 19:52:04 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Yuanhan Liu <yuanhan.liu@...ux.intel.com>,
	chris <chris@...is-wilson.co.uk>
Subject: Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters

On Tue, 2011-03-08 at 19:29 -0500, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@...dmis.org) wrote:
> > On Tue, 2011-03-08 at 19:07 -0500, Mathieu Desnoyers wrote:
> > 
> > > So what you are saying here is that modifying /etc/modprobe.d/ is the actual
> > > interface you propose presenting to the end-users to control their tracepoints ?
> > 
> > If you want to have them enabled on boot, sure.
> 
> No, I'm not talking about enabling tracepoints on boot here. Let's think about a
> basic use-case: a distro packages a tracer, and provides a "default" set of
> tracepoints that can be enabled when tracing is needed. Therefore, these
> tracepoints are not enabled at boot -- they are rather enabled when tracing
> starts. Some of these tracepoints are in dynamically loaded modules. Some of
> these modules are automatically loaded by the distro (e.g. when a USB device is
> plugged in).

What distro are we talking about? What distro provides a "default" set
of tracepoints?


> 
> The specific module tracepoints should therefore only be enabled when both of
> the following conditions are true:
> 
> A - the end-user want to trace
> B - the module is loaded
> 
> But it looks like hooking on modinfo will only let you unconditionally enable
> the module tracepoints during normal system operations (even when tracing is
> off), or not at all unless you previously load the module (which does not fit
> with the reality of distributions automagically loading modules on demand while
> tracing runs).

Lets keep it simple please. Right now my proposal does more than what we
currently have. Perhaps we could change the enabling to only enable if
"tracing is on", or some /proc/sys/kernel/X flag is set.


> > 
> > > Maybe I am missing something, but this interface seems to lack the layer of
> > > finish we might want to put into a user-visible API. I don't really see how
> > > distributions can hope to automate any of this for their end-user without making
> > > a mess of the /etc/modprobe.d/ they ship with.
> > 
> > What distros enable tracepoints by default?
> 
> Do you mean enable as having a probe connected, or just CONFIG_TRACEPOINTS=y ?

I mean having the probe connected as distros already have
CONFIG_TRACEPOINTS on. What was your meaning when you said "distro
specifying a basic set of tracepoints to enable"?


> 
> > 
> > If you want to enable a tracepoint on module load simply do:
> > 
> >  modprobe mymod trace_my_tracepoint=1
> > 
> > Otherwise modify your modprobe.d directory. This is the way users have
> > been doing module parameters for years.
> > 
> > That's pretty simple to me.
> 
> Everything is always so much easier when your end-user target is yourself.
> What are users for anyway ? :-P

Users are for testing code ;)

But that's a good question. As I wrote this because I'm purging my inbox
and came across Yuanhan Liu's patch set. I'm curios to what Yuanhan's
motivation for this change was.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ