public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Berg <johannes.berg@intel.com>
Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs
Date: Tue, 11 Mar 2014 10:26:50 -0400	[thread overview]
Message-ID: <20140311142650.GB13756@redhat.com> (raw)
In-Reply-To: <20140310225820.0f02025d@gandalf.local.home>

Hi, Steven -

> > So it is a deferred-activation kind of call, with no way of knowing
> > when or if the tracepoints will start coming in.  Why is that
> > supported at all, considering that clients could monitor modules
> > coming & going via the module_notifier chain, and update registration
> > at that time?
> 
> That's my argument.

Was there an answer?


> > >> +	entry = get_tracepoint(name);
> > >> +	/* Make sure the entry was enabled */
> > >> +	if (!entry || !entry->enabled)
> > >> +		ret = -ENODEV;
> > 
> > For what it's worth, I agree with Mathieu that this sort of successful
> > failure result code is a problem for tracking what needs cleanup and
> > what doesn't.  (In systemtap's case, if this change gets merged, we'll
> > have to treat -ENODEV as if it were 0.)
> 
> Does systemtap enable tracepoints before they are created? That is, do
> you allow enabling of a tracepoint in a module that is not loaded yet?

We have no formal opinion on whether or not this makes sense.  If the
kernel permits it, fine.

> If not, than you want this as an error.

But it's not exactly an error!  It's a success of sorts, and means
that later on we have to unregister the callback, just as if it were
successful.


- FChE

  parent reply	other threads:[~2014-03-11 14:27 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-07 15:09 [for-next][PATCH 00/20] tracing: linux-next updates Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 01/20] ftrace/x86: Run a sync after fixup on failure Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 02/20] ftrace/x86: One more missing sync after fixup of function modification failure Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 03/20] tracepoint: Do not waste memory on mods with no tracepoints Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 04/20] ftrace/x86: Have ftrace_write() return -EPERM and clean up callers Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 05/20] tracing: Move raw output code from macro to standalone function Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 06/20] tracing: Move event storage for array " Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 07/20] tracing: Use helper functions in event assignment to shrink macro size Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs Steven Rostedt
2014-03-10 20:01   ` Mathieu Desnoyers
2014-03-10 20:19     ` Steven Rostedt
2014-03-10 20:55       ` Mathieu Desnoyers
2014-03-11  2:41     ` Frank Ch. Eigler
2014-03-11  2:58       ` Steven Rostedt
2014-03-11  4:08         ` Mathieu Desnoyers
2014-03-11 14:46           ` Steven Rostedt
2014-03-11 14:26         ` Frank Ch. Eigler [this message]
2014-03-11 15:06           ` Mathieu Desnoyers
2014-03-11 15:40             ` Steven Rostedt
2014-03-11 17:34               ` Mathieu Desnoyers
2014-03-11 19:13                 ` Steven Rostedt
2014-03-12 14:24                   ` Mathieu Desnoyers
2014-03-12 15:11                     ` Steven Rostedt
2014-03-12 15:46                       ` Steven Rostedt
2014-03-12 16:05                         ` Mathieu Desnoyers
2014-03-12 16:18                           ` Steven Rostedt
2014-03-12 16:39                             ` Mathieu Desnoyers
2014-03-12 17:50                               ` Steven Rostedt
2014-03-12 18:47                                 ` Mathieu Desnoyers
2014-03-12 18:58                                   ` Steven Rostedt
2014-03-12 19:30                                     ` Steven Rostedt
2014-03-12 19:58                                       ` Mathieu Desnoyers
2014-03-12 19:51                                     ` Mathieu Desnoyers
2014-03-12 20:35                                       ` Andi Kleen
2014-03-12 20:47                                         ` Mathieu Desnoyers
2014-03-13  3:15                                           ` Andi Kleen
2014-03-13  3:21                                             ` Mathieu Desnoyers
2014-03-13  0:49                                       ` Steven Rostedt
2014-03-13  3:10                                         ` Mathieu Desnoyers
2014-03-13 15:24                                           ` Mathieu Desnoyers
2014-03-12 16:40                       ` Mathieu Desnoyers
2014-03-12 18:02                         ` Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 09/20] tracing: Fix event header writeback.h to include tracepoint.h Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 10/20] tracing: Fix event header migrate.h " Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 11/20] tracing/module: Replace include of tracepoint.h with jump_label.h in module.h Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 12/20] tracing: Correctly expand len expressions from __dynamic_array macro Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 13/20] tracing: Evaluate len expression only once in " Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 14/20] ftrace: Cleanup of global variables ftrace_new_pgs and ftrace_update_cnt Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 15/20] ftrace: Inline the code from ftrace_dyn_table_alloc() Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 16/20] ftrace: Pass retval through return in ftrace_dyn_arch_init() Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 17/20] ftrace: Do not pass data to ftrace_dyn_arch_init Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 18/20] ftrace: Remove freelist from struct dyn_ftrace Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 19/20] ftrace: Warn on error when modifying ftrace function Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 20/20] ftrace/x86: BUG when ftrace recovery fails Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140311142650.GB13756@redhat.com \
    --to=fche@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox