Messages in this thread | | | Date | Mon, 16 Nov 2009 17:39:49 -0500 | From | Masami Hiramatsu <> | Subject | 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
| |