From: Roland McGrath <roland@redhat.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>,
systemtap <systemtap@sources.redhat.com>,
DLE <dle-develop@lists.sourceforge.net>
Cc: Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH -tip 3/3] Add get_signal tracepoint
Date: Mon, 16 Nov 2009 22:11:00 -0000 [thread overview]
Message-ID: <20091116220957.8E2142F@magilla.sf.frob.com> (raw)
In-Reply-To: Masami Hiramatsu's message of Monday, 16 November 2009 16:51:23 -0500 <4B01C95B.1070302@redhat.com>
(I CC'd Oleg, who doesn't care much about tracepoints, but always stays up
to speed about all things related to signals.)
> > - signal IPI/wakeup events
>
> All signals might be used for IPI, isn't it? :-)
> Or, did you mean SIGSTOP/SIGCONT pare?
I suspect he means something approximating signal_wake_up() calls. If a
signal is blocked, ignored, already pending, etc., then the "sending" event
does not lead to any kind of wakeup or interrupt.
i.e. perhaps something like:
@@ -529,8 +529,11 @@ void signal_wake_up(struct task_struct *t, int resume)
mask = TASK_INTERRUPTIBLE;
if (resume)
mask |= TASK_WAKEKILL;
- if (!wake_up_state(t, mask))
+ trace_signal_wakeup(t, resume);
+ if (!wake_up_state(t, mask)) {
kick_process(t);
+ trace_signal_ipi(t, resume);
+ }
OTOH, kick_process() is only called from here.
Perhaps tracepoints in the sched layer can cover these.
Anyway, Ingo can be more precise about what he has in mind.
> > - 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).
Thanks,
Roland
next prev parent reply other threads:[~2009-11-16 22:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-13 22:52 [PATCH -tip 1/3] Pass mm->flags to binfmt core_dump for bitflag consistency Masami Hiramatsu
2009-11-13 22:52 ` [PATCH -tip 2/3] Add coredump tracepoint Masami Hiramatsu
2009-11-13 23:39 ` Roland McGrath
2009-11-14 0:00 ` Masami Hiramatsu
2009-11-14 0:02 ` Ingo Molnar
2009-11-14 0:06 ` Roland McGrath
2009-11-14 0:14 ` Ingo Molnar
2009-11-14 1:49 ` Roland McGrath
2009-11-14 0:26 ` Masami Hiramatsu
2009-11-13 22:52 ` [PATCH -tip 3/3] Add get_signal tracepoint Masami Hiramatsu
2009-11-13 23:53 ` Roland McGrath
2009-11-14 0:12 ` Ingo Molnar
2009-11-16 21:52 ` Masami Hiramatsu
2009-11-16 22:11 ` Roland McGrath [this message]
2009-11-16 22:40 ` Masami Hiramatsu
2009-11-16 23:01 ` Roland McGrath
2009-11-16 23:46 ` Masami Hiramatsu
2009-11-17 6:03 ` Ingo Molnar
2009-11-17 15:25 ` Masami Hiramatsu
2009-11-14 0:29 ` Masami Hiramatsu
2009-11-13 23:09 ` [PATCH -tip 1/3] Pass mm->flags to binfmt core_dump for bitflag consistency Andrew Morton
2009-11-13 23:25 ` Ingo Molnar
2009-11-13 23:45 ` Masami Hiramatsu
2009-11-13 23:16 ` Roland McGrath
2009-11-13 23:23 ` Ingo Molnar
2009-11-13 23:30 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091116220957.8E2142F@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=dle-develop@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).