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:	Wed, 12 Mar 2014 12:18:13 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	"Frank Ch. Eigler" <fche@...hat.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Berg <johannes.berg@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	lttng-dev <lttng-dev@...ts.lttng.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not
 set via debugfs

On Wed, 12 Mar 2014 16:05:36 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> ----- Original Message -----
> > From: "Steven Rostedt" <rostedt@...dmis.org>
> > To: "Mathieu Desnoyers" <mathieu.desnoyers@...icios.com>
> > Cc: "Frank Ch. Eigler" <fche@...hat.com>, linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...nel.org>, "Frederic
> > Weisbecker" <fweisbec@...il.com>, "Andrew Morton" <akpm@...ux-foundation.org>, "Johannes Berg"
> > <johannes.berg@...el.com>, "Linus Torvalds" <torvalds@...ux-foundation.org>, "Peter Zijlstra"
> > <peterz@...radead.org>, "Thomas Gleixner" <tglx@...utronix.de>, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
> > "lttng-dev" <lttng-dev@...ts.lttng.org>, "Rusty Russell" <rusty@...tcorp.com.au>
> > Sent: Wednesday, March 12, 2014 11:46:11 AM
> > Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs
> > 
> > 
> > To sum up this thread, and get the signal vs noise ratio up.
> > 
> > On Wed, 12 Mar 2014 11:11:00 -0400
> > Steven Rostedt <rostedt@...dmis.org> wrote:
> > 
> > 
> > > The solution I like the most that I believe will work for both of us,
> > > is to to move this magic "enable tracepoint in the future" to your
> > > LTTng module. Have your module register a module load and unload handler
> > > to be able to see the tracepoints that exist in the module, and you can
> > > enable them then. When a module is unloaded, your module can do the
> > > accounting to record that, and the state of its tracepoints.
> > 
> > This is my final proposal.
> > 
> > I'll add the patch that removes the tracepoint on failure along with
> > returning -ENODEV. That way, there will be no registered tracepoints
> > that do not exist.
> > 
> > I'll also make sure that on module unload, the tracepoints are disabled
> > for the module as well.
> 
> Do you mean that the tracepoint probe will be unregistered from within
> tracepoint.c whenever all modules containing tracepoint call sites are
> unloaded ? If so, how do you plan to handle ownership of the "name",
> "probe" and "data" pointer ? They belong to the tracer. Would they simply
> leak ?

Are you telling me it's not possible to delete the entire probe?

What I'm proposing is to do what the trace events do. Delete everything
associated to the tracepoints associated to the module.

> 
> > 
> > Then, you can simply add a module notifier that does the work that you
> > like, and save and restore the state of named tracepoints and enabled
> > them on module load. Just set the priority of the notifier to 1
> > so that it runs after the tracepoint notifier that adds the new
> > tracepoints to the system.
> 
> I don't mind the extra work on the LTTng side at all. What I am concerned
> about are changes that would make the tracepoint API sloppy.

I believe they are currently sloppy.

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