From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
"Frank Ch. Eigler" <fche@redhat.com>,
Jason Baron <jbaron@redhat.com>, Tom Zanussi <tzanussi@gmail.com>,
fweisbec@gmail.com, laijs@cn.fujitsu.com, rostedt@goodmis.org,
peterz@infradead.org, jiayingz@google.com, roland@redhat.com,
mbligh@google.com
Subject: [RFC patch 00/20] Kernel tracing thread flag
Date: Sat, 09 May 2009 12:22:09 -0400 [thread overview]
Message-ID: <20090509162209.217414024@polymtl.ca> (raw)
This is the generalisation of the TIF_SYSCALL_FTRACE thread flag for :
- multiple tracers (even accessible from modules)
- multiple architectures
It includes :
- Addition of the TIF_KERNEL_TRACE for all Linux architectures.
- Modification of some architecture entry*.S files to ensure that the thread
flag is re-read upon syscall exit to ensure that syscall exit is traced.
Basically, what I try to achieve here is to make sure that given the following
sequence will get its syscall exit event traced :
- Thread preempted in a system call
- Activation of all TIF_KERNEL_TRACE thread flags
- ...enough time passes to expect that all tracing sites are activated...
- syscall exit -> expected to be traced
But if the thread flags used at syscall exit are the same that has been read at
syscall entry, the event will be skipped. This does not permit reaching a known
"quiescent state" where we know that all tracing sites are activated.
Note that having non-perfectly matched syscall trace entry/exit may have
implications wrt getname/putname refcounting for instance, and could cause
problems if getname/putname was used in the syscall entry/exit pairs. We will
have to deal with this somehow when we face this problem. Keeping a per-thread
flag saying that a matching syscall_entry tracing has been executed could fix
this problem. We could even re-use TIF_SYSCALL_FTRACE for this specific purpose.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next reply other threads:[~2009-05-09 16:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-09 16:22 Mathieu Desnoyers [this message]
2009-05-09 16:22 ` [RFC patch 01/20] LTTng Kernel Trace Thread Flag Alpha Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 02/20] LTTng Kernel Trace Thread Flag ARM Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 03/20] LTTng Kernel Trace Thread Flag AVR32 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 04/20] LTTng Kernel Trace Thread Flag Blackfin Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 05/20] LTTng Kernel Trace Thread Flag Cris Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 06/20] LTTng Kernel Trace Thread Flag Frv Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 07/20] LTTng Kernel Trace Thread Flag H8300 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 08/20] LTTng Kernel Trace Thread Flag ia64 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 09/20] LTTng Kernel Trace Thread Flag m32r Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 10/20] LTTng Kernel Trace Thread Flag m68k Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 11/20] LTTng Kernel Trace Thread Flag MIPS Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 12/20] LTTng Kernel Trace Thread Flag parisc Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 13/20] LTTng Kernel Trace Thread Flag powerpc Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 14/20] LTTng Kernel Trace Thread Flag s390 Mathieu Desnoyers
2009-05-11 8:25 ` Heiko Carstens
2009-05-09 16:22 ` [RFC patch 15/20] LTTng Kernel Trace Thread Flag SH Mathieu Desnoyers
2009-05-09 17:15 ` Paul Mundt
2009-05-09 16:22 ` [RFC patch 16/20] LTTng Kernel Trace Thread Flag sparc Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 17/20] LTTng Kernel Trace Thread Flag UML Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 18/20] LTTng Linux Kernel Trace Thread Flag x86 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 19/20] LTTng Kernel Trace Thread Flag xtensa Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 20/20] LTTng Kernel Trace Thread Flag API Mathieu Desnoyers
2009-05-10 23:04 ` [RFC patch 00/20] Kernel tracing thread flag 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=20090509162209.217414024@polymtl.ca \
--to=mathieu.desnoyers@polymtl.ca \
--cc=akpm@linux-foundation.org \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jbaron@redhat.com \
--cc=jiayingz@google.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.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