Re: [PATCH -tip 3/3] Add get_signal tracepoint

From: Masami Hiramatsu
Date: Mon Nov 16 2009 - 17:42:15 EST


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

--
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/