This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip 3/3] Add get_signal tracepoint
Roland McGrath wrote:
- signal loss events (queue overflow)
Perhaps, this event is only for rt-signals, since
legacy signals just overwritten if it was sent.
Not exactly. Nothing is ever "overwritten". If a non-RT signal is already
pending, then you just leave the existing queue elements alone--i.e. the
first one isn't overwritten, rather the second one is dropped. But this is
not really the point.
The "queue overflow" happens in two ways. For RT signals it really is a
"signal loss" event--but that's also reported to the sender as -EAGAIN. So
a signal-generation tracepoint that reports the return value would already
cover that in a way.
For non-RT signals, a new signal is never lost. But __sigqueue_alloc() can
still fail. In this case, you get no queue element and thus no siginfo_t
stored, so you can lose some information about the signal. You don't lose
the signal itself, but will later dequeue it with an all-zeros siginfo_t.
While calling this a "signal loss" is inaccurate, it is indeed a silent
failure of sorts (unlike the RT signal case, which the userland caller
knows about from the return value).
Hmm, actually, trace_signal_send() doesn't record the return value.
So, what about trace_signal_overflow() for RT-signals and
trace_signal_loss_info() for non-RT?
e.g.
@@ -918,12 +918,15 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
break;
}
} else if (!is_si_special(info)) {
- if (sig >= SIGRTMIN && info->si_code != SI_USER)
+ if (sig >= SIGRTMIN && info->si_code != SI_USER) {
/*
* Queue overflow, abort. We may abort if the signal was rt
* and sent by user using something other than kill().
*/
+ trace_signal_overflow(sig, t);
return -EAGAIN;
+ }
+ trace_signal_loss_info(sig, info);
}
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com