[PATCH 0/2] (Was: Q: tracing: can we changetrace_signal_generate() signature?)

[Oleg Nesterov]

On 11/21, Steven Rostedt wrote:
>
> On Mon, 2011-11-21 at 21:21 +0100, Oleg Nesterov wrote:
>
> > 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? ;)

You are trolling me ;)

> > > > @@ -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.

Ah I see. I thought you dislike OVERFLOW_FAIL/LOSE_INFO namely.

Of course, you are right. OTOH, this patch shaves 1058 bytes from
.text. And without CONFIG_TRACE* gcc doesn't generate the extra code.



Oh. I simply do not know what can I do. Obviously, I'd like to avoid
the new tracepoints in __send_signal(), imho this would be ugly. But
the users want more info.

OK. let me send the patch at least for review. May be someone will
nack it authoritatively, in this case I can relax and forward the
nack back to bugzilla ;)

However, at least 2/2 looks very reasonable to me. In fact it looks
almost like the bug-fix.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/