From: Oleg Nesterov <oleg@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
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 21:21:10 +0100 [thread overview]
Message-ID: <20111121202110.GA27966@redhat.com> (raw)
In-Reply-To: <1321905799.20742.20.camel@frodo>
On 11/21, Steven Rostedt wrote:
>
> On Mon, 2011-11-21 at 20:19 +0100, Oleg Nesterov wrote:
> > Hello,
> >
> > Is it possible to change trace_signal_generate()'s args or this
> > is the part of the kernel ABI?
>
> As Linus said. It's only part of the ABI if a tool is using it. If you
> change it and no one complains, then it should be good to go.
I only I knew if it is used (and how) or not...
> > 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.
> > +enum {
> > + TRACE_SIGNAL_DELIVERED,
> > + TRACE_SIGNAL_IGNORED_OR_BLOCKED,
(can't understand why I added _OR_BLOCKED, it should be
TRACE_SIGNAL_IGNORED)
> > @@ -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...
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 20:25 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 [this message]
2011-11-21 21:52 ` Steven Rostedt
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=20111121202110.GA27966@redhat.com \
--to=oleg@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--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.