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

[Ingo Molnar <mingo at elte dot hu>]

* 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