Re: Q: tracing: can we change trace_signal_generate() signature?

Steven Rostedt
2011-11-21T21:52:39Z

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.