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

[Steven Rostedt <rostedt@goodmis.org>]

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.