From: Steven Rostedt <rostedt@goodmis.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@redhat.com>,
Masami Hiramatsu <mhiramat@redhat.com>,
Seiji Aguchi <saguchi@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Q: tracing: can we change trace_signal_generate() signature?
Date: Mon, 21 Nov 2011 16:52:36 -0500 [thread overview]
Message-ID: <1321912356.20742.24.camel@frodo> (raw)
In-Reply-To: <20111121202110.GA27966@redhat.com>
On Mon, 2011-11-21 at 21:21 +0100, Oleg Nesterov wrote:
> > > IOW. Ignoring the changes in include/trace/events/signal.h,
> > > can the patch below work or the changes like this are not
> > > allowed?
> >
> > I say change it and see who screams.
>
> Heh. How can I do this? The only thing I can do is: send the patch
> to the maintainer - you ;)
>
> OK. I'll send the patch "officially" tomorrow, let's see who nacks it.
I only maintain the tracing infrastructure. The tracepoint users are
maintained by the subsystem they are used in. Who's the signal
maintainer? ;)
>
> > > +enum {
> > > + TRACE_SIGNAL_DELIVERED,
> > > + TRACE_SIGNAL_IGNORED_OR_BLOCKED,
>
> (can't understand why I added _OR_BLOCKED, it should be
> TRACE_SIGNAL_IGNORED)
quilt refresh?
>
> > > @@ -1095,14 +1106,15 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
> > > * signal was rt and sent by user using something
> > > * other than kill().
> > > */
> > > - trace_signal_overflow_fail(sig, group, info);
> > > - return -EAGAIN;
> > > + result = TRACE_SIGNAL_OVERFLOW_FAIL;
> > > + ret = -EAGAIN;
> > > + goto ret;
> > > } else {
> > > /*
> > > * This is a silent loss of information. We still
> > > * send the signal, but the *info bits are lost.
> > > */
> > > - trace_signal_lose_info(sig, group, info);
> > > + result = TRACE_SIGNAL_LOSE_INFO;
> >
> > Hmm, all this result manipulation added for tracing that doesn't occur
> > in 99.99% of all machines?
>
> Not sure I understand...
Is "result" used for anything but tracepoints? When tracing is disabled,
the tracepoints should be just nops (when jump_label is enabled). Thus
tracing is very light. But if we are constantly calculating "result",
this is unused by those that don't use the tracing infrastructure, which
is 99.99% of all users. This is what I meant.
-- Steve
>
> With this patch trace_signal_generate() also reports "result" which
> allows to know was the signal actually delivered or not. And, if not,
> why it wasn't delivered.
>
> TRACE_SIGNAL_OVERFLOW_FAIL and TRACE_SIGNAL_LOSE_INFO are not really
> needed, but this way we can kill trace_signal_overflow_fail() and
> trace_signal_lose_info() and simplify the code.
>
> Oleg.
next prev parent reply other threads:[~2011-11-21 21:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-21 19:19 Q: tracing: can we change trace_signal_generate() signature? Oleg Nesterov
2011-11-21 20:03 ` Steven Rostedt
2011-11-21 20:21 ` Oleg Nesterov
2011-11-21 21:52 ` Steven Rostedt [this message]
2011-11-22 20:52 ` [PATCH 0/2] (Was: Q: tracing: can we change trace_signal_generate() signature?) Oleg Nesterov
2011-11-22 20:52 ` [PATCH 1/2] tracing: let trace_signal_generate() report more info, kill overflow_fail/lose_info Oleg Nesterov
2011-11-23 1:43 ` Li Zefan
2011-11-23 17:37 ` Oleg Nesterov
2011-11-30 16:24 ` Seiji Aguchi
2011-11-22 20:53 ` [PATCH 2/2] tracing: send_sigqueue() needs trace_signal_generate() too Oleg Nesterov
2011-11-30 16:24 ` Seiji Aguchi
2011-12-02 17:53 ` [PATCH 0/2] (Was: Q: tracing: can we change trace_signal_generate() signature?) Steven Rostedt
2011-12-19 17:04 ` [PATCH RESEND 0/2] tracing: signal tracepoints Oleg Nesterov
2011-12-19 17:05 ` [PATCH RESEND 1/2] tracing: let trace_signal_generate() report more info, kill overflow_fail/lose_info Oleg Nesterov
2011-12-19 17:05 ` [PATCH RESEND 2/2] tracing: send_sigqueue() needs trace_signal_generate() too Oleg Nesterov
2011-12-19 17:28 ` [PATCH RESEND 0/2] tracing: signal tracepoints Seiji Aguchi
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=1321912356.20742.24.camel@frodo \
--to=rostedt@goodmis.org \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=saguchi@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.