Messages in this thread | | | Subject | Re: Q: tracing: can we change trace_signal_generate() signature? | From | Steven Rostedt <> | Date | Mon, 21 Nov 2011 16:52:36 -0500 |
| |
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.
| |