Re: [PATCH -tip v3 0/3] tracepoint: Add signal events

Ingo Molnar
2009-11-24T21:56:31Z

* Oleg Nesterov <oleg@redhat.com> wrote:

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

well, there we lose information, so it's basically an exception/anomaly
that a person doing analysis might be interested in.

> OTOH, we do not report if __send_signal() fails just because the
> legacy signal is already queued. [...]

We could do that (beyond the queued signals full event), but i think
it's rather common to see signal overlap in the legacy case, right?

> [...] We do not report who sends the signal, [...]

The PID of any task generating an event can be sampled, so that's
implicit.

> [...] 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.

The principe is this: there's two extremes:

A- report no event

B- report every event precisely, that allows all signal state and
actions to be reconstructed in hindsight.

And there's a continuum between the two extremes. Just a random state
between A) and B) makes little sense - but certain subsets (say an
'overview' of major signal events) might make sense from an analysis
POV.

But the thing is, by my reading of these patches we are pretty close to
B) right now and the tracepoints still look sane - so we might as well
implement your suggestions and achieve B)? That's a well-defined target
to achieve. It would mean we need events of sigmask manipulations as
well, and handler setting events. Plus the missing events you pointed
out. (plus other stuff i might have forgotten about)

Ingo