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

[Oleg Nesterov <oleg@redhat.com>]

On 11/24, Ingo Molnar wrote:
>
> * Oleg Nesterov <oleg@redhat.com> wrote:
>
> > 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?

Yes, right. My point was, we do not know if people want to know
about "lost" signal in this case. Perhaps some application forgot
to unblock the signal, or the sender shouldn't send it, or the
reciever didn't react to the previous one.

But once again, I do not argue. I think the patches are nice and
useful. All I wanted to say is: I trust Masami and I have no idea
whether we need more or less info, and which events are more
"interesting".

> > [...] We do not report who sends the signal, [...]
>
> The PID of any task generating an event can be sampled, so that's
> implicit.

Yes, I missed this. If current != sender (timers, SIGIO) one can
look at entry->code = si_code.

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

Fortunately, Roland has already replied:

	> If we
	> need to change them, that will become clear from the experiences of people
	> actually using these.

In fact, the above is very close to what I meant but failed to explain ;)

Oleg.