Messages in this thread | | | Date | Tue, 24 Nov 2009 22:22:47 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH -tip v3 0/3] tracepoint: Add signal events |
| |
On 11/23, Ingo Molnar wrote: > > * Masami Hiramatsu <mhiramat@redhat.com> wrote: > > > Hi, > > > > These patches add signal related tracepoints including > > signal generation, delivery, and loss. First patch also > > moves signal-sending tracepoint from events/sched.h to > > events/signal.h. > > > > Changes in v3 > > - Add Docbook style comments > > > > Changes in v2 > > - Add siginfo arguments > > > > Thank you, > > > > --- > > > > Masami Hiramatsu (3): > > tracepoint: Add signal loss events > > tracepoint: Add signal deliver event > > tracepoint: Move signal sending tracepoint to events/signal.h > > > > > > Documentation/DocBook/tracepoint.tmpl | 5 + > > include/trace/events/sched.h | 25 ----- > > include/trace/events/signal.h | 173 +++++++++++++++++++++++++++++++++ > > kernel/signal.c | 27 ++++- > > 4 files changed, 198 insertions(+), 32 deletions(-) > > create mode 100644 include/trace/events/signal.h > > Would be nice to have Roland's and Oleg's Acked-by tags in the patches - > to show that this is a representative and useful looking set of signal > events.
Sorry, I can't really comment these patches.
I mean, I do not know which info is useful and which is not. For example, I am a bit surprized we report trace_signal_lose_info() but please do not consider this as if I think we shouldn't. Just I do not know.
OTOH, we do not report if __send_signal() fails just because the legacy signal is already queued. We do not report who sends the signal, we do not report if it was private or shared. zap_process, complete_signal can "send" SIGKILL via sigaddset, this won't be noticed. But again, it is not that I think this should be reported.
In short: I think any info may be useful, and these patches can help. But I do not understand what exactly should be reported to userspace.
Oleg.
| |