* [PATCH 0/3] utrace
@ 2009-03-21 1:39 Roland McGrath
2009-03-21 1:41 ` [PATCH 1/3] signals: tracehook_notify_jctl change Roland McGrath
` (2 more replies)
0 siblings, 3 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-21 1:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: utrace-devel, linux-kernel
utrace is a new kernel-side API for kernel modules, intended to make it
tractable to work on novel ways to trace and debug user-mode tasks.
These patches apply to the current Linus tree (v2.6.29-rc8-241-g65c2449).
The first two should apply fine on the -tip tree as well, and we will be
glad to rebase the set to whichever tree. Frank has another version of the
ftrace patch (3/3) that works for -tip. The utrace patches don't touch
anything unless you set a new kconfig option (still marked EXPERIMENTAL),
and so are quite safe in that regard.
utrace cannot be enabled without CONFIG_HAVE_ARCH_TRACEHOOK and the arch
details it indicates. If your arch does not have it yet, its maintainers
will have to work on that. The details are in the comments in arch/Kconfig.
The first patch makes a small update to one of the tracehook.h interfaces
that we needed for utrace. It moves code a little but does not change any
of the logic in the existing code.
The second patch adds the utrace kernel API (if CONFIG_UTRACE=y is set).
There is no change at all without the config option, and with it there is
no effect on anything at all until a kernel module using the utrace API is
loaded. There is detailed documentation on the API in DocBook form.
The third patch is an ftrace widget based on utrace, by Frank Eigler.
Frank will follow up on any issues about that patch.
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* [PATCH 1/3] signals: tracehook_notify_jctl change
2009-03-21 1:39 [PATCH 0/3] utrace Roland McGrath
@ 2009-03-21 1:41 ` Roland McGrath
2009-03-21 1:41 ` [PATCH 2/3] utrace core Roland McGrath
2009-03-21 1:42 ` [PATCH 3/3] utrace-based ftrace "process" engine, v2 Roland McGrath
2 siblings, 0 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-21 1:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: Oleg Nesterov, utrace-devel, linux-kernel
This changes tracehook_notify_jctl() so it's called with the siglock held,
and changes its argument and return value definition. These clean-ups make
it a better fit for what new tracing hooks need to check.
Tracing needs the siglock here, held from the time TASK_STOPPED was set,
to avoid potential SIGCONT races if it wants to allow any blocking in its
tracing hooks.
This also folds the finish_stop() function into its caller do_signal_stop().
The function is short, called only once and only unconditionally. It aids
readability to fold it in.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
include/linux/tracehook.h | 25 ++++++++++------
kernel/signal.c | 69 +++++++++++++++++++++++----------------------
2 files changed, 51 insertions(+), 43 deletions(-)
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 6186a78..b622498 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -1,7 +1,7 @@
/*
* Tracing hooks
*
- * Copyright (C) 2008 Red Hat, Inc. All rights reserved.
+ * Copyright (C) 2008-2009 Red Hat, Inc. All rights reserved.
*
* This copyrighted material is made available to anyone wishing to use,
* modify, copy, or redistribute it subject to the terms and conditions
@@ -469,22 +469,29 @@ static inline int tracehook_get_signal(s
/**
* tracehook_notify_jctl - report about job control stop/continue
- * @notify: nonzero if this is the last thread in the group to stop
+ * @notify: zero, %CLD_STOPPED or %CLD_CONTINUED
* @why: %CLD_STOPPED or %CLD_CONTINUED
*
* This is called when we might call do_notify_parent_cldstop().
- * It's called when about to stop for job control; we are already in
- * %TASK_STOPPED state, about to call schedule(). It's also called when
- * a delayed %CLD_STOPPED or %CLD_CONTINUED report is ready to be made.
*
- * Return nonzero to generate a %SIGCHLD with @why, which is
- * normal if @notify is nonzero.
+ * @notify is zero if we would not ordinarily send a %SIGCHLD,
+ * or is the %CLD_STOPPED or %CLD_CONTINUED .si_code for %SIGCHLD.
*
- * Called with no locks held.
+ * @why is %CLD_STOPPED when about to stop for job control;
+ * we are already in %TASK_STOPPED state, about to call schedule().
+ * It might also be that we have just exited (check %PF_EXITING),
+ * but need to report that a group-wide stop is complete.
+ *
+ * @why is %CLD_CONTINUED when waking up after job control stop and
+ * ready to make a delayed @notify report.
+ *
+ * Return the %CLD_* value for %SIGCHLD, or zero to generate no signal.
+ *
+ * Called with the siglock held.
*/
static inline int tracehook_notify_jctl(int notify, int why)
{
- return notify || (current->ptrace & PT_PTRACED);
+ return notify ?: (current->ptrace & PT_PTRACED) ? why : 0;
}
#define DEATH_REAP -1
diff --git a/kernel/signal.c b/kernel/signal.c
index 2a74fe8..9a0d98f 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -691,7 +691,7 @@ static int prepare_signal(int sig, struc
if (why) {
/*
- * The first thread which returns from finish_stop()
+ * The first thread which returns from do_signal_stop()
* will take ->siglock, notice SIGNAL_CLD_MASK, and
* notify its parent. See get_signal_to_deliver().
*/
@@ -1629,29 +1629,6 @@ void ptrace_notify(int exit_code)
spin_unlock_irq(¤t->sighand->siglock);
}
-static void
-finish_stop(int stop_count)
-{
- /*
- * If there are no other threads in the group, or if there is
- * a group stop in progress and we are the last to stop,
- * report to the parent. When ptraced, every thread reports itself.
- */
- if (tracehook_notify_jctl(stop_count == 0, CLD_STOPPED)) {
- read_lock(&tasklist_lock);
- do_notify_parent_cldstop(current, CLD_STOPPED);
- read_unlock(&tasklist_lock);
- }
-
- do {
- schedule();
- } while (try_to_freeze());
- /*
- * Now we don't run again until continued.
- */
- current->exit_code = 0;
-}
-
/*
* This performs the stopping for SIGSTOP and other stop signals.
* We have to stop all threads in the thread group.
@@ -1662,6 +1639,7 @@ static int do_signal_stop(int signr)
{
struct signal_struct *sig = current->signal;
int stop_count;
+ int notify;
if (sig->group_stop_count > 0) {
/*
@@ -1701,8 +1679,30 @@ static int do_signal_stop(int signr)
current->exit_code = sig->group_exit_code;
__set_current_state(TASK_STOPPED);
+ /*
+ * If there are no other threads in the group, or if there is
+ * a group stop in progress and we are the last to stop,
+ * report to the parent. When ptraced, every thread reports itself.
+ */
+ notify = tracehook_notify_jctl(stop_count == 0 ? CLD_STOPPED : 0,
+ CLD_STOPPED);
+
spin_unlock_irq(¤t->sighand->siglock);
- finish_stop(stop_count);
+
+ if (notify) {
+ read_lock(&tasklist_lock);
+ do_notify_parent_cldstop(current, notify);
+ read_unlock(&tasklist_lock);
+ }
+
+ do {
+ schedule();
+ } while (try_to_freeze());
+ /*
+ * Now we don't run again until continued.
+ */
+ current->exit_code = 0;
+
return 1;
}
@@ -1771,14 +1771,15 @@ relock:
int why = (signal->flags & SIGNAL_STOP_CONTINUED)
? CLD_CONTINUED : CLD_STOPPED;
signal->flags &= ~SIGNAL_CLD_MASK;
- spin_unlock_irq(&sighand->siglock);
- if (unlikely(!tracehook_notify_jctl(1, why)))
- goto relock;
+ why = tracehook_notify_jctl(why, CLD_CONTINUED);
+ spin_unlock_irq(&sighand->siglock);
- read_lock(&tasklist_lock);
- do_notify_parent_cldstop(current->group_leader, why);
- read_unlock(&tasklist_lock);
+ if (why) {
+ read_lock(&tasklist_lock);
+ do_notify_parent_cldstop(current->group_leader, why);
+ read_unlock(&tasklist_lock);
+ }
goto relock;
}
@@ -1936,14 +1937,14 @@ void exit_signals(struct task_struct *ts
if (unlikely(tsk->signal->group_stop_count) &&
!--tsk->signal->group_stop_count) {
tsk->signal->flags = SIGNAL_STOP_STOPPED;
- group_stop = 1;
+ group_stop = tracehook_notify_jctl(CLD_STOPPED, CLD_STOPPED);
}
out:
spin_unlock_irq(&tsk->sighand->siglock);
- if (unlikely(group_stop) && tracehook_notify_jctl(1, CLD_STOPPED)) {
+ if (unlikely(group_stop)) {
read_lock(&tasklist_lock);
- do_notify_parent_cldstop(tsk, CLD_STOPPED);
+ do_notify_parent_cldstop(tsk, group_stop);
read_unlock(&tasklist_lock);
}
}
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 2/3] utrace core
2009-03-21 1:39 [PATCH 0/3] utrace Roland McGrath
2009-03-21 1:41 ` [PATCH 1/3] signals: tracehook_notify_jctl change Roland McGrath
@ 2009-03-21 1:41 ` Roland McGrath
2009-03-21 8:49 ` Andrew Morton
2009-03-21 1:42 ` [PATCH 3/3] utrace-based ftrace "process" engine, v2 Roland McGrath
2 siblings, 1 reply; 53+ messages in thread
From: Roland McGrath @ 2009-03-21 1:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: utrace-devel, linux-kernel
This adds the utrace facility, a new modular interface in the kernel for
implementing user thread tracing and debugging. This fits on top of the
tracehook_* layer, so the new code is well-isolated.
The new interface is in <linux/utrace.h> and the DocBook utrace book
describes it. It allows for multiple separate tracing engines to work in
parallel without interfering with each other. Higher-level tracing
facilities can be implemented as loadable kernel modules using this layer.
The new facility is made optional under CONFIG_UTRACE.
When this is not enabled, no new code is added.
It can only be enabled on machines that have all the
prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK.
In this initial version, utrace and ptrace do not play together at all.
If ptrace is attached to a thread, the attach calls in the utrace kernel
API return -EBUSY. If utrace is attached to a thread, the PTRACE_ATTACH
or PTRACE_TRACEME request will return EBUSY to userland. The old ptrace
code is otherwise unchanged and nothing using ptrace should be affected
by this patch as long as utrace is not used at the same time. In the
future we can clean up the ptrace implementation and rework it to use
the utrace API.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
Documentation/DocBook/Makefile | 2 +-
Documentation/DocBook/utrace.tmpl | 571 +++++++++
fs/proc/array.c | 3 +
include/linux/init_task.h | 1 +
include/linux/sched.h | 6 +
include/linux/tracehook.h | 50 +-
include/linux/utrace.h | 692 +++++++++++
include/linux/utrace_struct.h | 58 +
init/Kconfig | 9 +
kernel/Makefile | 1 +
kernel/ptrace.c | 18 +-
kernel/utrace.c | 2348 +++++++++++++++++++++++++++++++++++++
12 files changed, 3756 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 1462ed8..f5da1b4 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -9,7 +9,7 @@
DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
procfs-guide.xml writing_usb_driver.xml networking.xml \
- kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
+ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml utrace.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml debugobjects.xml sh.xml regulator.xml
diff --git a/Documentation/DocBook/utrace.tmpl b/Documentation/DocBook/utrace.tmpl
new file mode 100644
index ...b802c55 100644
--- /dev/null
+++ b/Documentation/DocBook/utrace.tmpl
@@ -0,0 +1,571 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+
+<book id="utrace">
+ <bookinfo>
+ <title>The utrace User Debugging Infrastructure</title>
+ </bookinfo>
+
+ <toc></toc>
+
+ <chapter id="concepts"><title>utrace concepts</title>
+
+ <sect1 id="intro"><title>Introduction</title>
+
+ <para>
+ <application>utrace</application> is infrastructure code for tracing
+ and controlling user threads. This is the foundation for writing
+ tracing engines, which can be loadable kernel modules.
+ </para>
+
+ <para>
+ The basic actors in <application>utrace</application> are the thread
+ and the tracing engine. A tracing engine is some body of code that
+ calls into the <filename><linux/utrace.h></filename>
+ interfaces, represented by a <structname>struct
+ utrace_engine_ops</structname>. (Usually it's a kernel module,
+ though the legacy <function>ptrace</function> support is a tracing
+ engine that is not in a kernel module.) The interface operates on
+ individual threads (<structname>struct task_struct</structname>).
+ If an engine wants to treat several threads as a group, that is up
+ to its higher-level code.
+ </para>
+
+ <para>
+ Tracing begins by attaching an engine to a thread, using
+ <function>utrace_attach_task</function> or
+ <function>utrace_attach_pid</function>. If successful, it returns a
+ pointer that is the handle used in all other calls.
+ </para>
+
+ </sect1>
+
+ <sect1 id="callbacks"><title>Events and Callbacks</title>
+
+ <para>
+ An attached engine does nothing by default. An engine makes something
+ happen by requesting callbacks via <function>utrace_set_events</function>
+ and poking the thread with <function>utrace_control</function>.
+ The synchronization issues related to these two calls
+ are discussed further below in <xref linkend="teardown"/>.
+ </para>
+
+ <para>
+ Events are specified using the macro
+ <constant>UTRACE_EVENT(<replaceable>type</replaceable>)</constant>.
+ Each event type is associated with a callback in <structname>struct
+ utrace_engine_ops</structname>. A tracing engine can leave unused
+ callbacks <constant>NULL</constant>. The only callbacks required
+ are those used by the event flags it sets.
+ </para>
+
+ <para>
+ Many engines can be attached to each thread. When a thread has an
+ event, each engine gets a callback if it has set the event flag for
+ that event type. Engines are called in the order they attached.
+ Engines that attach after the event has occurred do not get callbacks
+ for that event. This includes any new engines just attached by an
+ existing engine's callback function. Once the sequence of callbacks
+ for that one event has completed, such new engines are then eligible in
+ the next sequence that starts when there is another event.
+ </para>
+
+ <para>
+ Event reporting callbacks have details particular to the event type,
+ but are all called in similar environments and have the same
+ constraints. Callbacks are made from safe points, where no locks
+ are held, no special resources are pinned (usually), and the
+ user-mode state of the thread is accessible. So, callback code has
+ a pretty free hand. But to be a good citizen, callback code should
+ never block for long periods. It is fine to block in
+ <function>kmalloc</function> and the like, but never wait for i/o or
+ for user mode to do something. If you need the thread to wait, use
+ <constant>UTRACE_STOP</constant> and return from the callback
+ quickly. When your i/o finishes or whatever, you can use
+ <function>utrace_control</function> to resume the thread.
+ </para>
+
+ </sect1>
+
+ <sect1 id="safely"><title>Stopping Safely</title>
+
+ <sect2 id="well-behaved"><title>Writing well-behaved callbacks</title>
+
+ <para>
+ Well-behaved callbacks are important to maintain two essential
+ properties of the interface. The first of these is that unrelated
+ tracing engines should not interfere with each other. If your engine's
+ event callback does not return quickly, then another engine won't get
+ the event notification in a timely manner. The second important
+ property is that tracing should be as noninvasive as possible to the
+ normal operation of the system overall and of the traced thread in
+ particular. That is, attached tracing engines should not perturb a
+ thread's behavior, except to the extent that changing its user-visible
+ state is explicitly what you want to do. (Obviously some perturbation
+ is unavoidable, primarily timing changes, ranging from small delays due
+ to the overhead of tracing, to arbitrary pauses in user code execution
+ when a user stops a thread with a debugger for examination.) Even when
+ you explicitly want the perturbation of making the traced thread block,
+ just blocking directly in your callback has more unwanted effects. For
+ example, the <constant>CLONE</constant> event callbacks are called when
+ the new child thread has been created but not yet started running; the
+ child can never be scheduled until the <constant>CLONE</constant>
+ tracing callbacks return. (This allows engines tracing the parent to
+ attach to the child.) If a <constant>CLONE</constant> event callback
+ blocks the parent thread, it also prevents the child thread from
+ running (even to process a <constant>SIGKILL</constant>). If what you
+ want is to make both the parent and child block, then use
+ <function>utrace_attach_task</function> on the child and then use
+ <constant>UTRACE_STOP</constant> on both threads. A more crucial
+ problem with blocking in callbacks is that it can prevent
+ <constant>SIGKILL</constant> from working. A thread that is blocking
+ due to <constant>UTRACE_STOP</constant> will still wake up and die
+ immediately when sent a <constant>SIGKILL</constant>, as all threads
+ should. Relying on the <application>utrace</application>
+ infrastructure rather than on private synchronization calls in event
+ callbacks is an important way to help keep tracing robustly
+ noninvasive.
+ </para>
+
+ </sect2>
+
+ <sect2 id="UTRACE_STOP"><title>Using <constant>UTRACE_STOP</constant></title>
+
+ <para>
+ To control another thread and access its state, it must be stopped
+ with <constant>UTRACE_STOP</constant>. This means that it is
+ stopped and won't start running again while we access it. When a
+ thread is not already stopped, <function>utrace_control</function>
+ returns <constant>-EINPROGRESS</constant> and an engine must wait
+ for an event callback when the thread is ready to stop. The thread
+ may be running on another CPU or may be blocked. When it is ready
+ to be examined, it will make callbacks to engines that set the
+ <constant>UTRACE_EVENT(QUIESCE)</constant> event bit. To wake up an
+ interruptible wait, use <constant>UTRACE_INTERRUPT</constant>.
+ </para>
+
+ <para>
+ As long as some engine has used <constant>UTRACE_STOP</constant> and
+ not called <function>utrace_control</function> to resume the thread,
+ then the thread will remain stopped. <constant>SIGKILL</constant>
+ will wake it up, but it will not run user code. When the stop is
+ cleared with <function>utrace_control</function> or a callback
+ return value, the thread starts running again.
+ (See also <xref linkend="teardown"/>.)
+ </para>
+
+ </sect2>
+
+ </sect1>
+
+ <sect1 id="teardown"><title>Tear-down Races</title>
+
+ <sect2 id="SIGKILL"><title>Primacy of <constant>SIGKILL</constant></title>
+ <para>
+ Ordinarily synchronization issues for tracing engines are kept fairly
+ straightforward by using <constant>UTRACE_STOP</constant>. You ask a
+ thread to stop, and then once it makes the
+ <function>report_quiesce</function> callback it cannot do anything else
+ that would result in another callback, until you let it with a
+ <function>utrace_control</function> call. This simple arrangement
+ avoids complex and error-prone code in each one of a tracing engine's
+ event callbacks to keep them serialized with the engine's other
+ operations done on that thread from another thread of control.
+ However, giving tracing engines complete power to keep a traced thread
+ stuck in place runs afoul of a more important kind of simplicity that
+ the kernel overall guarantees: nothing can prevent or delay
+ <constant>SIGKILL</constant> from making a thread die and release its
+ resources. To preserve this important property of
+ <constant>SIGKILL</constant>, it as a special case can break
+ <constant>UTRACE_STOP</constant> like nothing else normally can. This
+ includes both explicit <constant>SIGKILL</constant> signals and the
+ implicit <constant>SIGKILL</constant> sent to each other thread in the
+ same thread group by a thread doing an exec, or processing a fatal
+ signal, or making an <function>exit_group</function> system call. A
+ tracing engine can prevent a thread from beginning the exit or exec or
+ dying by signal (other than <constant>SIGKILL</constant>) if it is
+ attached to that thread, but once the operation begins, no tracing
+ engine can prevent or delay all other threads in the same thread group
+ dying.
+ </para>
+ </sect2>
+
+ <sect2 id="reap"><title>Final callbacks</title>
+ <para>
+ The <function>report_reap</function> callback is always the final event
+ in the life cycle of a traced thread. Tracing engines can use this as
+ the trigger to clean up their own data structures. The
+ <function>report_death</function> callback is always the penultimate
+ event a tracing engine might see; it's seen unless the thread was
+ already in the midst of dying when the engine attached. Many tracing
+ engines will have no interest in when a parent reaps a dead process,
+ and nothing they want to do with a zombie thread once it dies; for
+ them, the <function>report_death</function> callback is the natural
+ place to clean up data structures and detach. To facilitate writing
+ such engines robustly, given the asynchrony of
+ <constant>SIGKILL</constant>, and without error-prone manual
+ implementation of synchronization schemes, the
+ <application>utrace</application> infrastructure provides some special
+ guarantees about the <function>report_death</function> and
+ <function>report_reap</function> callbacks. It still takes some care
+ to be sure your tracing engine is robust to tear-down races, but these
+ rules make it reasonably straightforward and concise to handle a lot of
+ corner cases correctly.
+ </para>
+ </sect2>
+
+ <sect2 id="refcount"><title>Engine and task pointers</title>
+ <para>
+ The first sort of guarantee concerns the core data structures
+ themselves. <structname>struct utrace_engine</structname> is
+ a reference-counted data structure. While you hold a reference, an
+ engine pointer will always stay valid so that you can safely pass it to
+ any <application>utrace</application> call. Each call to
+ <function>utrace_attach_task</function> or
+ <function>utrace_attach_pid</function> returns an engine pointer with a
+ reference belonging to the caller. You own that reference until you
+ drop it using <function>utrace_engine_put</function>. There is an
+ implicit reference on the engine while it is attached. So if you drop
+ your only reference, and then use
+ <function>utrace_attach_task</function> without
+ <constant>UTRACE_ATTACH_CREATE</constant> to look up that same engine,
+ you will get the same pointer with a new reference to replace the one
+ you dropped, just like calling <function>utrace_engine_get</function>.
+ When an engine has been detached, either explicitly with
+ <constant>UTRACE_DETACH</constant> or implicitly after
+ <function>report_reap</function>, then any references you hold are all
+ that keep the old engine pointer alive.
+ </para>
+
+ <para>
+ There is nothing a kernel module can do to keep a <structname>struct
+ task_struct</structname> alive outside of
+ <function>rcu_read_lock</function>. When the task dies and is reaped
+ by its parent (or itself), that structure can be freed so that any
+ dangling pointers you have stored become invalid.
+ <application>utrace</application> will not prevent this, but it can
+ help you detect it safely. By definition, a task that has been reaped
+ has had all its engines detached. All
+ <application>utrace</application> calls can be safely called on a
+ detached engine if the caller holds a reference on that engine pointer,
+ even if the task pointer passed in the call is invalid. All calls
+ return <constant>-ESRCH</constant> for a detached engine, which tells
+ you that the task pointer you passed could be invalid now. Since
+ <function>utrace_control</function> and
+ <function>utrace_set_events</function> do not block, you can call those
+ inside a <function>rcu_read_lock</function> section and be sure after
+ they don't return <constant>-ESRCH</constant> that the task pointer is
+ still valid until <function>rcu_read_unlock</function>. The
+ infrastructure never holds task references of its own. Though neither
+ <function>rcu_read_lock</function> nor any other lock is held while
+ making a callback, it's always guaranteed that the <structname>struct
+ task_struct</structname> and the <structname>struct
+ utrace_engine</structname> passed as arguments remain valid
+ until the callback function returns.
+ </para>
+
+ <para>
+ The common means for safely holding task pointers that is available to
+ kernel modules is to use <structname>struct pid</structname>, which
+ permits <function>put_pid</function> from kernel modules. When using
+ that, the calls <function>utrace_attach_pid</function>,
+ <function>utrace_control_pid</function>,
+ <function>utrace_set_events_pid</function>, and
+ <function>utrace_barrier_pid</function> are available.
+ </para>
+ </sect2>
+
+ <sect2 id="reap-after-death">
+ <title>
+ Serialization of <constant>DEATH</constant> and <constant>REAP</constant>
+ </title>
+ <para>
+ The second guarantee is the serialization of
+ <constant>DEATH</constant> and <constant>REAP</constant> event
+ callbacks for a given thread. The actual reaping by the parent
+ (<function>release_task</function> call) can occur simultaneously
+ while the thread is still doing the final steps of dying, including
+ the <function>report_death</function> callback. If a tracing engine
+ has requested both <constant>DEATH</constant> and
+ <constant>REAP</constant> event reports, it's guaranteed that the
+ <function>report_reap</function> callback will not be made until
+ after the <function>report_death</function> callback has returned.
+ If the <function>report_death</function> callback itself detaches
+ from the thread, then the <function>report_reap</function> callback
+ will never be made. Thus it is safe for a
+ <function>report_death</function> callback to clean up data
+ structures and detach.
+ </para>
+ </sect2>
+
+ <sect2 id="interlock"><title>Interlock with final callbacks</title>
+ <para>
+ The final sort of guarantee is that a tracing engine will know for sure
+ whether or not the <function>report_death</function> and/or
+ <function>report_reap</function> callbacks will be made for a certain
+ thread. These tear-down races are disambiguated by the error return
+ values of <function>utrace_set_events</function> and
+ <function>utrace_control</function>. Normally
+ <function>utrace_control</function> called with
+ <constant>UTRACE_DETACH</constant> returns zero, and this means that no
+ more callbacks will be made. If the thread is in the midst of dying,
+ it returns <constant>-EALREADY</constant> to indicate that the
+ <constant>report_death</constant> callback may already be in progress;
+ when you get this error, you know that any cleanup your
+ <function>report_death</function> callback does is about to happen or
+ has just happened--note that if the <function>report_death</function>
+ callback does not detach, the engine remains attached until the thread
+ gets reaped. If the thread is in the midst of being reaped,
+ <function>utrace_control</function> returns <constant>-ESRCH</constant>
+ to indicate that the <function>report_reap</function> callback may
+ already be in progress; this means the engine is implicitly detached
+ when the callback completes. This makes it possible for a tracing
+ engine that has decided asynchronously to detach from a thread to
+ safely clean up its data structures, knowing that no
+ <function>report_death</function> or <function>report_reap</function>
+ callback will try to do the same. <constant>utrace_detach</constant>
+ returns <constant>-ESRCH</constant> when the <structname>struct
+ utrace_engine</structname> has already been detached, but is
+ still a valid pointer because of its reference count. A tracing engine
+ can use this to safely synchronize its own independent multiple threads
+ of control with each other and with its event callbacks that detach.
+ </para>
+
+ <para>
+ In the same vein, <function>utrace_set_events</function> normally
+ returns zero; if the target thread was stopped before the call, then
+ after a successful call, no event callbacks not requested in the new
+ flags will be made. It fails with <constant>-EALREADY</constant> if
+ you try to clear <constant>UTRACE_EVENT(DEATH)</constant> when the
+ <function>report_death</function> callback may already have begun, if
+ you try to clear <constant>UTRACE_EVENT(REAP)</constant> when the
+ <function>report_reap</function> callback may already have begun, or if
+ you try to newly set <constant>UTRACE_EVENT(DEATH)</constant> or
+ <constant>UTRACE_EVENT(QUIESCE)</constant> when the target is already
+ dead or dying. Like <function>utrace_control</function>, it returns
+ <constant>-ESRCH</constant> when the thread has already been detached
+ (including forcible detach on reaping). This lets the tracing engine
+ know for sure which event callbacks it will or won't see after
+ <function>utrace_set_events</function> has returned. By checking for
+ errors, it can know whether to clean up its data structures immediately
+ or to let its callbacks do the work.
+ </para>
+ </sect2>
+
+ <sect2 id="barrier"><title>Using <function>utrace_barrier</function></title>
+ <para>
+ When a thread is safely stopped, calling
+ <function>utrace_control</function> with <constant>UTRACE_DETACH</constant>
+ or calling <function>utrace_set_events</function> to disable some events
+ ensures synchronously that your engine won't get any more of the callbacks
+ that have been disabled (none at all when detaching). But these can also
+ be used while the thread is not stopped, when it might be simultaneously
+ making a callback to your engine. For this situation, these calls return
+ <constant>-EINPROGRESS</constant> when it's possible a callback is in
+ progress. If you are not prepared to have your old callbacks still run,
+ then you can synchronize to be sure all the old callbacks are finished,
+ using <function>utrace_barrier</function>. This is necessary if the
+ kernel module containing your callback code is going to be unloaded.
+ </para>
+ <para>
+ After using <constant>UTRACE_DETACH</constant> once, further calls to
+ <function>utrace_control</function> with the same engine pointer will
+ return <constant>-ESRCH</constant>. In contrast, after getting
+ <constant>-EINPROGRESS</constant> from
+ <function>utrace_set_events</function>, you can call
+ <function>utrace_set_events</function> again later and if it returns zero
+ then know the old callbacks have finished.
+ </para>
+ <para>
+ Unlike all other calls, <function>utrace_barrier</function> (and
+ <function>utrace_barrier_pid</function>) will accept any engine pointer you
+ hold a reference on, even if <constant>UTRACE_DETACH</constant> has already
+ been used. After any <function>utrace_control</function> or
+ <function>utrace_set_events</function> call (these do not block), you can
+ call <function>utrace_barrier</function> to block until callbacks have
+ finished. This returns <constant>-ESRCH</constant> only if the engine is
+ completely detached (finished all callbacks). Otherwise it waits
+ until the thread is definitely not in the midst of a callback to this
+ engine and then returns zero, but can return
+ <constant>-ERESTARTSYS</constant> if its wait is interrupted.
+ </para>
+ </sect2>
+
+</sect1>
+
+</chapter>
+
+<chapter id="core"><title>utrace core API</title>
+
+<para>
+ The utrace API is declared in <filename><linux/utrace.h></filename>.
+</para>
+
+!Iinclude/linux/utrace.h
+!Ekernel/utrace.c
+
+</chapter>
+
+<chapter id="machine"><title>Machine State</title>
+
+<para>
+ The <function>task_current_syscall</function> function can be used on any
+ valid <structname>struct task_struct</structname> at any time, and does
+ not even require that <function>utrace_attach_task</function> was used at all.
+</para>
+
+<para>
+ The other ways to access the registers and other machine-dependent state of
+ a task can only be used on a task that is at a known safe point. The safe
+ points are all the places where <function>utrace_set_events</function> can
+ request callbacks (except for the <constant>DEATH</constant> and
+ <constant>REAP</constant> events). So at any event callback, it is safe to
+ examine <varname>current</varname>.
+</para>
+
+<para>
+ One task can examine another only after a callback in the target task that
+ returns <constant>UTRACE_STOP</constant> so that task will not return to user
+ mode after the safe point. This guarantees that the task will not resume
+ until the same engine uses <function>utrace_control</function>, unless the
+ task dies suddenly. To examine safely, one must use a pair of calls to
+ <function>utrace_prepare_examine</function> and
+ <function>utrace_finish_examine</function> surrounding the calls to
+ <structname>struct user_regset</structname> functions or direct examination
+ of task data structures. <function>utrace_prepare_examine</function> returns
+ an error if the task is not properly stopped and not dead. After a
+ successful examination, the paired <function>utrace_finish_examine</function>
+ call returns an error if the task ever woke up during the examination. If
+ so, any data gathered may be scrambled and should be discarded. This means
+ there was a spurious wake-up (which should not happen), or a sudden death.
+</para>
+
+<sect1 id="regset"><title><structname>struct user_regset</structname></title>
+
+<para>
+ The <structname>struct user_regset</structname> API
+ is declared in <filename><linux/regset.h></filename>.
+</para>
+
+!Finclude/linux/regset.h
+
+</sect1>
+
+<sect1 id="task_current_syscall">
+ <title><filename>System Call Information</filename></title>
+
+<para>
+ This function is declared in <filename><linux/ptrace.h></filename>.
+</para>
+
+!Elib/syscall.c
+
+</sect1>
+
+<sect1 id="syscall"><title><filename>System Call Tracing</filename></title>
+
+<para>
+ The arch API for system call information is declared in
+ <filename><asm/syscall.h></filename>.
+ Each of these calls can be used only at system call entry tracing,
+ or can be used only at system call exit and the subsequent safe points
+ before returning to user mode.
+ At system call entry tracing means either during a
+ <structfield>report_syscall_entry</structfield> callback,
+ or any time after that callback has returned <constant>UTRACE_STOP</constant>.
+</para>
+
+!Finclude/asm-generic/syscall.h
+
+</sect1>
+
+</chapter>
+
+<chapter id="internals"><title>Kernel Internals</title>
+
+<para>
+ This chapter covers the interface to the tracing infrastructure
+ from the core of the kernel and the architecture-specific code.
+ This is for maintainers of the kernel and arch code, and not relevant
+ to using the tracing facilities described in preceding chapters.
+</para>
+
+<sect1 id="tracehook"><title>Core Calls In</title>
+
+<para>
+ These calls are declared in <filename><linux/tracehook.h></filename>.
+ The core kernel calls these functions at various important places.
+</para>
+
+!Finclude/linux/tracehook.h
+
+</sect1>
+
+<sect1 id="arch"><title>Architecture Calls Out</title>
+
+<para>
+ An arch that has done all these things sets
+ <constant>CONFIG_HAVE_ARCH_TRACEHOOK</constant>.
+ This is required to enable the <application>utrace</application> code.
+</para>
+
+<sect2 id="arch-ptrace"><title><filename><asm/ptrace.h></filename></title>
+
+<para>
+ An arch defines these in <filename><asm/ptrace.h></filename>
+ if it supports hardware single-step or block-step features.
+</para>
+
+!Finclude/linux/ptrace.h arch_has_single_step arch_has_block_step
+!Finclude/linux/ptrace.h user_enable_single_step user_enable_block_step
+!Finclude/linux/ptrace.h user_disable_single_step
+
+</sect2>
+
+<sect2 id="arch-syscall">
+ <title><filename><asm/syscall.h></filename></title>
+
+ <para>
+ An arch provides <filename><asm/syscall.h></filename> that
+ defines these as inlines, or declares them as exported functions.
+ These interfaces are described in <xref linkend="syscall"/>.
+ </para>
+
+</sect2>
+
+<sect2 id="arch-tracehook">
+ <title><filename><linux/tracehook.h></filename></title>
+
+ <para>
+ An arch must define <constant>TIF_NOTIFY_RESUME</constant>
+ and <constant>TIF_SYSCALL_TRACE</constant>
+ in its <filename><asm/thread_info.h></filename>.
+ The arch code must call the following functions, all declared
+ in <filename><linux/tracehook.h></filename> and
+ described in <xref linkend="tracehook"/>:
+
+ <itemizedlist>
+ <listitem>
+ <para><function>tracehook_notify_resume</function></para>
+ </listitem>
+ <listitem>
+ <para><function>tracehook_report_syscall_entry</function></para>
+ </listitem>
+ <listitem>
+ <para><function>tracehook_report_syscall_exit</function></para>
+ </listitem>
+ <listitem>
+ <para><function>tracehook_signal_handler</function></para>
+ </listitem>
+ </itemizedlist>
+
+ </para>
+
+</sect2>
+
+</sect1>
+
+</chapter>
+
+</book>
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 7e4877d..0c683ed 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -81,6 +81,7 @@
#include <linux/seq_file.h>
#include <linux/pid_namespace.h>
#include <linux/tracehook.h>
+#include <linux/utrace.h>
#include <asm/pgtable.h>
#include <asm/processor.h>
@@ -187,6 +188,8 @@ static inline void task_state(struct seq
cred->uid, cred->euid, cred->suid, cred->fsuid,
cred->gid, cred->egid, cred->sgid, cred->fsgid);
+ task_utrace_proc_status(m, p);
+
task_lock(p);
if (p->files)
fdt = files_fdtable(p->files);
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index e752d97..39eebc8 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -181,6 +181,7 @@ extern struct cred init_cred;
[PIDTYPE_SID] = INIT_PID_LINK(PIDTYPE_SID), \
}, \
.dirties = INIT_PROP_LOCAL_SINGLE(dirties), \
+ INIT_UTRACE(tsk) \
INIT_IDS \
INIT_TRACE_IRQFLAGS \
INIT_LOCKDEP \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 011db2f..786ef2d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -59,6 +59,7 @@ struct sched_param {
#include <linux/errno.h>
#include <linux/nodemask.h>
#include <linux/mm_types.h>
+#include <linux/utrace_struct.h>
#include <asm/system.h>
#include <asm/page.h>
@@ -1287,6 +1288,11 @@ struct task_struct {
#endif
seccomp_t seccomp;
+#ifdef CONFIG_UTRACE
+ struct utrace utrace;
+ unsigned long utrace_flags;
+#endif
+
/* Thread group tracking */
u32 parent_exec_id;
u32 self_exec_id;
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index b622498..6ff7277 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -49,6 +49,7 @@
#include <linux/sched.h>
#include <linux/ptrace.h>
#include <linux/security.h>
+#include <linux/utrace.h>
struct linux_binprm;
/**
@@ -63,6 +64,8 @@ struct linux_binprm;
*/
static inline int tracehook_expect_breakpoints(struct task_struct *task)
{
+ if (unlikely(task_utrace_flags(task) & UTRACE_EVENT(SIGNAL_CORE)))
+ return 1;
return (task_ptrace(task) & PT_PTRACED) != 0;
}
@@ -111,6 +114,9 @@ static inline void ptrace_report_syscall
static inline __must_check int tracehook_report_syscall_entry(
struct pt_regs *regs)
{
+ if ((task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_ENTRY)) &&
+ utrace_report_syscall_entry(regs))
+ return 1;
ptrace_report_syscall(regs);
return 0;
}
@@ -134,6 +140,8 @@ static inline __must_check int tracehook
*/
static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
{
+ if (task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_EXIT))
+ utrace_report_syscall_exit(regs);
ptrace_report_syscall(regs);
}
@@ -194,6 +202,8 @@ static inline void tracehook_report_exec
struct linux_binprm *bprm,
struct pt_regs *regs)
{
+ if (unlikely(task_utrace_flags(current) & UTRACE_EVENT(EXEC)))
+ utrace_report_exec(fmt, bprm, regs);
if (!ptrace_event(PT_TRACE_EXEC, PTRACE_EVENT_EXEC, 0) &&
unlikely(task_ptrace(current) & PT_PTRACED))
send_sig(SIGTRAP, current, 0);
@@ -211,6 +221,8 @@ static inline void tracehook_report_exec
*/
static inline void tracehook_report_exit(long *exit_code)
{
+ if (unlikely(task_utrace_flags(current) & UTRACE_EVENT(EXIT)))
+ utrace_report_exit(exit_code);
ptrace_event(PT_TRACE_EXIT, PTRACE_EVENT_EXIT, *exit_code);
}
@@ -254,6 +266,7 @@ static inline int tracehook_prepare_clon
static inline void tracehook_finish_clone(struct task_struct *child,
unsigned long clone_flags, int trace)
{
+ utrace_init_task(child);
ptrace_init_task(child, (clone_flags & CLONE_PTRACE) || trace);
}
@@ -280,6 +293,8 @@ static inline void tracehook_report_clon
unsigned long clone_flags,
pid_t pid, struct task_struct *child)
{
+ if (unlikely(task_utrace_flags(current) & UTRACE_EVENT(CLONE)))
+ utrace_report_clone(clone_flags, child);
if (unlikely(trace) || unlikely(clone_flags & CLONE_PTRACE)) {
/*
* The child starts up with an immediate SIGSTOP.
@@ -311,6 +326,9 @@ static inline void tracehook_report_clon
pid_t pid,
struct task_struct *child)
{
+ if (unlikely(task_utrace_flags(current) & UTRACE_EVENT(CLONE)) &&
+ (clone_flags & CLONE_VFORK))
+ utrace_finish_vfork(current);
if (unlikely(trace))
ptrace_event(0, trace, pid);
}
@@ -345,6 +363,7 @@ static inline void tracehook_report_vfor
*/
static inline void tracehook_prepare_release_task(struct task_struct *task)
{
+ utrace_release_task(task);
}
/**
@@ -359,6 +378,7 @@ static inline void tracehook_prepare_rel
static inline void tracehook_finish_release_task(struct task_struct *task)
{
ptrace_release_task(task);
+ BUG_ON(task->exit_state != EXIT_DEAD);
}
/**
@@ -380,6 +400,8 @@ static inline void tracehook_signal_hand
const struct k_sigaction *ka,
struct pt_regs *regs, int stepping)
{
+ if (task_utrace_flags(current))
+ utrace_signal_handler(current, stepping);
if (stepping)
ptrace_notify(SIGTRAP);
}
@@ -400,6 +422,8 @@ static inline int tracehook_consider_ign
int sig,
void __user *handler)
{
+ if (unlikely(task_utrace_flags(task) & UTRACE_EVENT(SIGNAL_IGN)))
+ return 1;
return (task_ptrace(task) & PT_PTRACED) != 0;
}
@@ -421,6 +445,9 @@ static inline int tracehook_consider_fat
int sig,
void __user *handler)
{
+ if (unlikely(task_utrace_flags(task) & (UTRACE_EVENT(SIGNAL_TERM) |
+ UTRACE_EVENT(SIGNAL_CORE))))
+ return 1;
return (task_ptrace(task) & PT_PTRACED) != 0;
}
@@ -435,6 +462,8 @@ static inline int tracehook_consider_fat
*/
static inline int tracehook_force_sigpending(void)
{
+ if (unlikely(task_utrace_flags(current)))
+ return utrace_interrupt_pending();
return 0;
}
@@ -464,6 +493,8 @@ static inline int tracehook_get_signal(s
siginfo_t *info,
struct k_sigaction *return_ka)
{
+ if (unlikely(task_utrace_flags(task)))
+ return utrace_get_signal(task, regs, info, return_ka);
return 0;
}
@@ -491,6 +522,8 @@ static inline int tracehook_get_signal(s
*/
static inline int tracehook_notify_jctl(int notify, int why)
{
+ if (task_utrace_flags(current) & UTRACE_EVENT(JCTL))
+ utrace_report_jctl(notify, why);
return notify ?: (current->ptrace & PT_PTRACED) ? why : 0;
}
@@ -514,6 +547,8 @@ static inline int tracehook_notify_jctl(
static inline int tracehook_notify_death(struct task_struct *task,
void **death_cookie, int group_dead)
{
+ *death_cookie = task_utrace_struct(task);
+
if (task->exit_signal == -1)
return task->ptrace ? SIGCHLD : DEATH_REAP;
@@ -550,6 +585,9 @@ static inline void tracehook_report_deat
int signal, void *death_cookie,
int group_dead)
{
+ smp_mb();
+ if (task_utrace_flags(task) & _UTRACE_DEATH_EVENTS)
+ utrace_report_death(task, death_cookie, group_dead, signal);
}
#ifdef TIF_NOTIFY_RESUME
@@ -579,10 +617,20 @@ static inline void set_notify_resume(str
* asynchronously, this will be called again before we return to
* user mode.
*
- * Called without locks.
+ * Called without locks. However, on some machines this may be
+ * called with interrupts disabled.
*/
static inline void tracehook_notify_resume(struct pt_regs *regs)
{
+ struct task_struct *task = current;
+ /*
+ * This pairs with the barrier implicit in set_notify_resume().
+ * It ensures that we read the nonzero utrace_flags set before
+ * set_notify_resume() was called by utrace setup.
+ */
+ smp_rmb();
+ if (task_utrace_flags(task))
+ utrace_resume(task, regs);
}
#endif /* TIF_NOTIFY_RESUME */
diff --git a/include/linux/utrace.h b/include/linux/utrace.h
new file mode 100644
index ...f46cc0f 100644
--- /dev/null
+++ b/include/linux/utrace.h
@@ -0,0 +1,692 @@
+/*
+ * utrace infrastructure interface for debugging user processes
+ *
+ * Copyright (C) 2006-2009 Red Hat, Inc. All rights reserved.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU General Public License v.2.
+ *
+ * Red Hat Author: Roland McGrath.
+ *
+ * This interface allows for notification of interesting events in a
+ * thread. It also mediates access to thread state such as registers.
+ * Multiple unrelated users can be associated with a single thread.
+ * We call each of these a tracing engine.
+ *
+ * A tracing engine starts by calling utrace_attach_task() or
+ * utrace_attach_pid() on the chosen thread, passing in a set of hooks
+ * (&struct utrace_engine_ops), and some associated data. This produces a
+ * &struct utrace_engine, which is the handle used for all other
+ * operations. An attached engine has its ops vector, its data, and an
+ * event mask controlled by utrace_set_events().
+ *
+ * For each event bit that is set, that engine will get the
+ * appropriate ops->report_*() callback when the event occurs. The
+ * &struct utrace_engine_ops need not provide callbacks for an event
+ * unless the engine sets one of the associated event bits.
+ */
+
+#ifndef _LINUX_UTRACE_H
+#define _LINUX_UTRACE_H 1
+
+#include <linux/list.h>
+#include <linux/kref.h>
+#include <linux/signal.h>
+#include <linux/sched.h>
+
+struct linux_binprm;
+struct pt_regs;
+struct utrace;
+struct user_regset;
+struct user_regset_view;
+
+/*
+ * Event bits passed to utrace_set_events().
+ * These appear in &struct task_struct.@utrace_flags
+ * and &struct utrace_engine.@flags.
+ */
+enum utrace_events {
+ _UTRACE_EVENT_QUIESCE, /* Thread is available for examination. */
+ _UTRACE_EVENT_REAP, /* Zombie reaped, no more tracing possible. */
+ _UTRACE_EVENT_CLONE, /* Successful clone/fork/vfork just done. */
+ _UTRACE_EVENT_EXEC, /* Successful execve just completed. */
+ _UTRACE_EVENT_EXIT, /* Thread exit in progress. */
+ _UTRACE_EVENT_DEATH, /* Thread has died. */
+ _UTRACE_EVENT_SYSCALL_ENTRY, /* User entered kernel for system call. */
+ _UTRACE_EVENT_SYSCALL_EXIT, /* Returning to user after system call. */
+ _UTRACE_EVENT_SIGNAL, /* Signal delivery will run a user handler. */
+ _UTRACE_EVENT_SIGNAL_IGN, /* No-op signal to be delivered. */
+ _UTRACE_EVENT_SIGNAL_STOP, /* Signal delivery will suspend. */
+ _UTRACE_EVENT_SIGNAL_TERM, /* Signal delivery will terminate. */
+ _UTRACE_EVENT_SIGNAL_CORE, /* Signal delivery will dump core. */
+ _UTRACE_EVENT_JCTL, /* Job control stop or continue completed. */
+ _UTRACE_NEVENTS
+};
+#define UTRACE_EVENT(type) (1UL << _UTRACE_EVENT_##type)
+
+/*
+ * All the kinds of signal events.
+ * These all use the @report_signal() callback.
+ */
+#define UTRACE_EVENT_SIGNAL_ALL (UTRACE_EVENT(SIGNAL) \
+ | UTRACE_EVENT(SIGNAL_IGN) \
+ | UTRACE_EVENT(SIGNAL_STOP) \
+ | UTRACE_EVENT(SIGNAL_TERM) \
+ | UTRACE_EVENT(SIGNAL_CORE))
+/*
+ * Both kinds of syscall events; these call the @report_syscall_entry()
+ * and @report_syscall_exit() callbacks, respectively.
+ */
+#define UTRACE_EVENT_SYSCALL \
+ (UTRACE_EVENT(SYSCALL_ENTRY) | UTRACE_EVENT(SYSCALL_EXIT))
+
+/*
+ * The event reports triggered synchronously by task death.
+ */
+#define _UTRACE_DEATH_EVENTS (UTRACE_EVENT(DEATH) | UTRACE_EVENT(QUIESCE))
+
+/*
+ * Hooks in <linux/tracehook.h> call these entry points to the
+ * utrace dispatch. They are weak references here only so
+ * tracehook.h doesn't need to #ifndef CONFIG_UTRACE them to
+ * avoid external references in case of unoptimized compilation.
+ */
+bool utrace_interrupt_pending(void)
+ __attribute__((weak));
+void utrace_resume(struct task_struct *, struct pt_regs *)
+ __attribute__((weak));
+int utrace_get_signal(struct task_struct *, struct pt_regs *,
+ siginfo_t *, struct k_sigaction *)
+ __attribute__((weak));
+void utrace_report_clone(unsigned long, struct task_struct *)
+ __attribute__((weak));
+void utrace_finish_vfork(struct task_struct *)
+ __attribute__((weak));
+void utrace_report_exit(long *exit_code)
+ __attribute__((weak));
+void utrace_report_death(struct task_struct *, struct utrace *, bool, int)
+ __attribute__((weak));
+void utrace_report_jctl(int notify, int type)
+ __attribute__((weak));
+void utrace_report_exec(struct linux_binfmt *, struct linux_binprm *,
+ struct pt_regs *regs)
+ __attribute__((weak));
+bool utrace_report_syscall_entry(struct pt_regs *)
+ __attribute__((weak));
+void utrace_report_syscall_exit(struct pt_regs *)
+ __attribute__((weak));
+void utrace_signal_handler(struct task_struct *, int)
+ __attribute__((weak));
+
+#ifndef CONFIG_UTRACE
+
+/*
+ * <linux/tracehook.h> uses these accessors to avoid #ifdef CONFIG_UTRACE.
+ */
+static inline unsigned long task_utrace_flags(struct task_struct *task)
+{
+ return 0;
+}
+static inline struct utrace *task_utrace_struct(struct task_struct *task)
+{
+ return NULL;
+}
+static inline void utrace_init_task(struct task_struct *child)
+{
+}
+static inline void utrace_release_task(struct task_struct *task)
+{
+}
+
+static inline void task_utrace_proc_status(struct seq_file *m,
+ struct task_struct *p)
+{
+}
+
+#else /* CONFIG_UTRACE */
+
+static inline unsigned long task_utrace_flags(struct task_struct *task)
+{
+ return task->utrace_flags;
+}
+
+static inline struct utrace *task_utrace_struct(struct task_struct *task)
+{
+ return &task->utrace;
+}
+
+static inline void utrace_init_task(struct task_struct *task)
+{
+ task->utrace_flags = 0;
+ memset(&task->utrace, 0, sizeof(task->utrace));
+ INIT_LIST_HEAD(&task->utrace.attached);
+ INIT_LIST_HEAD(&task->utrace.attaching);
+ spin_lock_init(&task->utrace.lock);
+}
+
+void utrace_release_task(struct task_struct *);
+void task_utrace_proc_status(struct seq_file *m, struct task_struct *p);
+
+
+/*
+ * Version number of the API defined in this file. This will change
+ * whenever a tracing engine's code would need some updates to keep
+ * working. We maintain this here for the benefit of tracing engine code
+ * that is developed concurrently with utrace API improvements before they
+ * are merged into the kernel, making LINUX_VERSION_CODE checks unwieldy.
+ */
+#define UTRACE_API_VERSION 20090302
+
+/**
+ * enum utrace_resume_action - engine's choice of action for a traced task
+ * @UTRACE_STOP: Stay quiescent after callbacks.
+ * @UTRACE_REPORT: Make some callback soon.
+ * @UTRACE_INTERRUPT: Make @report_signal() callback soon.
+ * @UTRACE_SINGLESTEP: Resume in user mode for one instruction.
+ * @UTRACE_BLOCKSTEP: Resume in user mode until next branch.
+ * @UTRACE_RESUME: Resume normally in user mode.
+ * @UTRACE_DETACH: Detach my engine (implies %UTRACE_RESUME).
+ *
+ * See utrace_control() for detailed descriptions of each action. This is
+ * encoded in the @action argument and the return value for every callback
+ * with a &u32 return value.
+ *
+ * The order of these is important. When there is more than one engine,
+ * each supplies its choice and the smallest value prevails.
+ */
+enum utrace_resume_action {
+ UTRACE_STOP,
+ UTRACE_REPORT,
+ UTRACE_INTERRUPT,
+ UTRACE_SINGLESTEP,
+ UTRACE_BLOCKSTEP,
+ UTRACE_RESUME,
+ UTRACE_DETACH
+};
+#define UTRACE_RESUME_MASK 0x0f
+
+/**
+ * utrace_resume_action - &enum utrace_resume_action from callback action
+ * @action: &u32 callback @action argument or return value
+ *
+ * This extracts the &enum utrace_resume_action from @action,
+ * which is the @action argument to a &struct utrace_engine_ops
+ * callback or the return value from one.
+ */
+static inline enum utrace_resume_action utrace_resume_action(u32 action)
+{
+ return action & UTRACE_RESUME_MASK;
+}
+
+/**
+ * enum utrace_signal_action - disposition of signal
+ * @UTRACE_SIGNAL_DELIVER: Deliver according to sigaction.
+ * @UTRACE_SIGNAL_IGN: Ignore the signal.
+ * @UTRACE_SIGNAL_TERM: Terminate the process.
+ * @UTRACE_SIGNAL_CORE: Terminate with core dump.
+ * @UTRACE_SIGNAL_STOP: Deliver as absolute stop.
+ * @UTRACE_SIGNAL_TSTP: Deliver as job control stop.
+ * @UTRACE_SIGNAL_REPORT: Reporting before pending signals.
+ * @UTRACE_SIGNAL_HANDLER: Reporting after signal handler setup.
+ *
+ * This is encoded in the @action argument and the return value for
+ * a @report_signal() callback. It says what will happen to the
+ * signal described by the &siginfo_t parameter to the callback.
+ *
+ * The %UTRACE_SIGNAL_REPORT value is used in an @action argument when
+ * a tracing report is being made before dequeuing any pending signal.
+ * If this is immediately after a signal handler has been set up, then
+ * %UTRACE_SIGNAL_HANDLER is used instead. A @report_signal callback
+ * that uses %UTRACE_SIGNAL_DELIVER|%UTRACE_SINGLESTEP will ensure
+ * it sees a %UTRACE_SIGNAL_HANDLER report.
+ */
+enum utrace_signal_action {
+ UTRACE_SIGNAL_DELIVER = 0x00,
+ UTRACE_SIGNAL_IGN = 0x10,
+ UTRACE_SIGNAL_TERM = 0x20,
+ UTRACE_SIGNAL_CORE = 0x30,
+ UTRACE_SIGNAL_STOP = 0x40,
+ UTRACE_SIGNAL_TSTP = 0x50,
+ UTRACE_SIGNAL_REPORT = 0x60,
+ UTRACE_SIGNAL_HANDLER = 0x70
+};
+#define UTRACE_SIGNAL_MASK 0xf0
+#define UTRACE_SIGNAL_HOLD 0x100 /* Flag, push signal back on queue. */
+
+/**
+ * utrace_signal_action - &enum utrace_signal_action from callback action
+ * @action: @report_signal callback @action argument or return value
+ *
+ * This extracts the &enum utrace_signal_action from @action, which
+ * is the @action argument to a @report_signal callback or the
+ * return value from one.
+ */
+static inline enum utrace_signal_action utrace_signal_action(u32 action)
+{
+ return action & UTRACE_SIGNAL_MASK;
+}
+
+/**
+ * enum utrace_syscall_action - disposition of system call attempt
+ * @UTRACE_SYSCALL_RUN: Run the system call.
+ * @UTRACE_SYSCALL_ABORT: Don't run the system call.
+ *
+ * This is encoded in the @action argument and the return value for
+ * a @report_syscall_entry callback.
+ */
+enum utrace_syscall_action {
+ UTRACE_SYSCALL_RUN = 0x00,
+ UTRACE_SYSCALL_ABORT = 0x10
+};
+#define UTRACE_SYSCALL_MASK 0xf0
+
+/**
+ * utrace_syscall_action - &enum utrace_syscall_action from callback action
+ * @action: @report_syscall_entry callback @action or return value
+ *
+ * This extracts the &enum utrace_syscall_action from @action, which
+ * is the @action argument to a @report_syscall_entry callback or the
+ * return value from one.
+ */
+static inline enum utrace_syscall_action utrace_syscall_action(u32 action)
+{
+ return action & UTRACE_SYSCALL_MASK;
+}
+
+/*
+ * Flags for utrace_attach_task() and utrace_attach_pid().
+ */
+#define UTRACE_ATTACH_CREATE 0x0010 /* Attach a new engine. */
+#define UTRACE_ATTACH_EXCLUSIVE 0x0020 /* Refuse if existing match. */
+#define UTRACE_ATTACH_MATCH_OPS 0x0001 /* Match engines on ops. */
+#define UTRACE_ATTACH_MATCH_DATA 0x0002 /* Match engines on data. */
+#define UTRACE_ATTACH_MATCH_MASK 0x000f
+
+/**
+ * struct utrace_engine - per-engine structure
+ * @ops: &struct utrace_engine_ops pointer passed to utrace_attach_task()
+ * @data: engine-private &void * passed to utrace_attach_task()
+ * @flags: event mask set by utrace_set_events() plus internal flag bits
+ *
+ * The task itself never has to worry about engines detaching while
+ * it's doing event callbacks. These structures are removed from the
+ * task's active list only when it's stopped, or by the task itself.
+ *
+ * utrace_engine_get() and utrace_engine_put() maintain a reference count.
+ * When it drops to zero, the structure is freed. One reference is held
+ * implicitly while the engine is attached to its task.
+ */
+struct utrace_engine {
+/* private: */
+ struct kref kref;
+ struct list_head entry;
+
+/* public: */
+ const struct utrace_engine_ops *ops;
+ void *data;
+
+ unsigned long flags;
+};
+
+/**
+ * utrace_engine_get - acquire a reference on a &struct utrace_engine
+ * @engine: &struct utrace_engine pointer
+ *
+ * You must hold a reference on @engine, and you get another.
+ */
+static inline void utrace_engine_get(struct utrace_engine *engine)
+{
+ kref_get(&engine->kref);
+}
+
+void __utrace_engine_release(struct kref *);
+
+/**
+ * utrace_engine_put - release a reference on a &struct utrace_engine
+ * @engine: &struct utrace_engine pointer
+ *
+ * You must hold a reference on @engine, and you lose that reference.
+ * If it was the last one, @engine becomes an invalid pointer.
+ */
+static inline void utrace_engine_put(struct utrace_engine *engine)
+{
+ kref_put(&engine->kref, __utrace_engine_release);
+}
+
+/**
+ * struct utrace_engine_ops - tracing engine callbacks
+ *
+ * Each @report_*() callback corresponds to an %UTRACE_EVENT(*) bit.
+ * utrace_set_events() calls on @engine choose which callbacks will be made
+ * to @engine from @task.
+ *
+ * Most callbacks take an @action argument, giving the resume action
+ * chosen by other tracing engines. All callbacks take an @engine
+ * argument, and a @task argument, which is always equal to @current.
+ * For some calls, @action also includes bits specific to that event
+ * and utrace_resume_action() is used to extract the resume action.
+ * This shows what would happen if @engine wasn't there, or will if
+ * the callback's return value uses %UTRACE_RESUME. This always
+ * starts as %UTRACE_RESUME when no other tracing is being done on
+ * this task.
+ *
+ * All return values contain &enum utrace_resume_action bits. For
+ * some calls, other bits specific to that kind of event are added to
+ * the resume action bits with OR. These are the same bits used in
+ * the @action argument. The resume action returned by a callback
+ * does not override previous engines' choices, it only says what
+ * @engine wants done. What @task actually does is the action that's
+ * most constrained among the choices made by all attached engines.
+ * See utrace_control() for more information on the actions.
+ *
+ * When %UTRACE_STOP is used in @report_syscall_entry, then @task
+ * stops before attempting the system call. In other cases, the
+ * resume action does not take effect until @task is ready to check
+ * for signals and return to user mode. If there are more callbacks
+ * to be made, the last round of calls determines the final action.
+ * A @report_quiesce callback with @event zero, or a @report_signal
+ * callback, will always be the last one made before @task resumes.
+ * Only %UTRACE_STOP is "sticky"--if @engine returned %UTRACE_STOP
+ * then @task stays stopped unless @engine returns different from a
+ * following callback.
+ *
+ * The report_death() and report_reap() callbacks do not take @action
+ * arguments, and only %UTRACE_DETACH is meaningful in the return value
+ * from a report_death() callback. None of the resume actions applies
+ * to a dead thread.
+ *
+ * All @report_*() hooks are called with no locks held, in a generally
+ * safe environment when we will be returning to user mode soon (or just
+ * entered the kernel). It is fine to block for memory allocation and
+ * the like, but all hooks are asynchronous and must not block on
+ * external events! If you want the thread to block, use %UTRACE_STOP
+ * in your hook's return value; then later wake it up with utrace_control().
+ *
+ * @report_quiesce:
+ * Requested by %UTRACE_EVENT(%QUIESCE).
+ * This does not indicate any event, but just that @task (the current
+ * thread) is in a safe place for examination. This call is made
+ * before each specific event callback, except for @report_reap.
+ * The @event argument gives the %UTRACE_EVENT(@which) value for
+ * the event occurring. This callback might be made for events @engine
+ * has not requested, if some other engine is tracing the event;
+ * calling utrace_set_events() call here can request the immediate
+ * callback for this occurrence of @event. @event is zero when there
+ * is no other event, @task is now ready to check for signals and
+ * return to user mode, and some engine has used %UTRACE_REPORT or
+ * %UTRACE_INTERRUPT to request this callback. For this case,
+ * if @report_signal is not %NULL, the @report_quiesce callback
+ * may be replaced with a @report_signal callback passing
+ * %UTRACE_SIGNAL_REPORT in its @action argument, whenever @task is
+ * entering the signal-check path anyway.
+ *
+ * @report_signal:
+ * Requested by %UTRACE_EVENT(%SIGNAL_*) or %UTRACE_EVENT(%QUIESCE).
+ * Use utrace_signal_action() and utrace_resume_action() on @action.
+ * The signal action is %UTRACE_SIGNAL_REPORT when some engine has
+ * used %UTRACE_REPORT or %UTRACE_INTERRUPT; the callback can choose
+ * to stop or to deliver an artificial signal, before pending signals.
+ * It's %UTRACE_SIGNAL_HANDLER instead when signal handler setup just
+ * finished (after a previous %UTRACE_SIGNAL_DELIVER return); this
+ * serves in lieu of any %UTRACE_SIGNAL_REPORT callback requested by
+ * %UTRACE_REPORT or %UTRACE_INTERRUPT, and is also implicitly
+ * requested by %UTRACE_SINGLESTEP or %UTRACE_BLOCKSTEP into the
+ * signal delivery. The other signal actions indicate a signal about
+ * to be delivered; the previous engine's return value sets the signal
+ * action seen by the the following engine's callback. The @info data
+ * can be changed at will, including @info->si_signo. The settings in
+ * @return_ka determines what %UTRACE_SIGNAL_DELIVER does. @orig_ka
+ * is what was in force before other tracing engines intervened, and
+ * it's %NULL when this report began as %UTRACE_SIGNAL_REPORT or
+ * %UTRACE_SIGNAL_HANDLER. For a report without a new signal, @info
+ * is left uninitialized and must be set completely by an engine that
+ * chooses to deliver a signal; if there was a previous @report_signal
+ * callback ending in %UTRACE_STOP and it was just resumed using
+ * %UTRACE_REPORT or %UTRACE_INTERRUPT, then @info is left unchanged
+ * from the previous callback. In this way, the original signal can
+ * be left in @info while returning %UTRACE_STOP|%UTRACE_SIGNAL_IGN
+ * and then found again when resuming @task with %UTRACE_INTERRUPT.
+ * The %UTRACE_SIGNAL_HOLD flag bit can be OR'd into the return value,
+ * and might be in @action if the previous engine returned it. This
+ * flag asks that the signal in @info be pushed back on @task's queue
+ * so that it will be seen again after whatever action is taken now.
+ *
+ * @report_clone:
+ * Requested by %UTRACE_EVENT(%CLONE).
+ * Event reported for parent, before the new task @child might run.
+ * @clone_flags gives the flags used in the clone system call,
+ * or equivalent flags for a fork() or vfork() system call.
+ * This function can use utrace_attach_task() on @child. It's guaranteed
+ * that asynchronous utrace_attach_task() calls will be ordered after
+ * any calls in @report_clone callbacks for the parent. Thus
+ * when using %UTRACE_ATTACH_EXCLUSIVE in the asynchronous calls,
+ * you can be sure that the parent's @report_clone callback has
+ * already attached to @child or chosen not to. Passing %UTRACE_STOP
+ * to utrace_control() on @child here keeps the child stopped before
+ * it ever runs in user mode, %UTRACE_REPORT or %UTRACE_INTERRUPT
+ * ensures a callback from @child before it starts in user mode.
+ *
+ * @report_jctl:
+ * Requested by %UTRACE_EVENT(%JCTL).
+ * Job control event; @type is %CLD_STOPPED or %CLD_CONTINUED,
+ * indicating whether we are stopping or resuming now. If @notify
+ * is nonzero, @task is the last thread to stop and so will send
+ * %SIGCHLD to its parent after this callback; @notify reflects
+ * what the parent's %SIGCHLD has in @si_code, which can sometimes
+ * be %CLD_STOPPED even when @type is %CLD_CONTINUED.
+ *
+ * @report_exec:
+ * Requested by %UTRACE_EVENT(%EXEC).
+ * An execve system call has succeeded and the new program is about to
+ * start running. The initial user register state is handy to be tweaked
+ * directly in @regs. @fmt and @bprm gives the details of this exec.
+ *
+ * @report_syscall_entry:
+ * Requested by %UTRACE_EVENT(%SYSCALL_ENTRY).
+ * Thread has entered the kernel to request a system call.
+ * The user register state is handy to be tweaked directly in @regs.
+ * The @action argument contains an &enum utrace_syscall_action,
+ * use utrace_syscall_action() to extract it. The return value
+ * overrides the last engine's action for the system call.
+ * If the final action is %UTRACE_SYSCALL_ABORT, no system call
+ * is made. The details of the system call being attempted can
+ * be fetched here with syscall_get_nr() and syscall_get_arguments().
+ * The parameter registers can be changed with syscall_set_arguments().
+ *
+ * @report_syscall_exit:
+ * Requested by %UTRACE_EVENT(%SYSCALL_EXIT).
+ * Thread is about to leave the kernel after a system call request.
+ * The user register state is handy to be tweaked directly in @regs.
+ * The results of the system call attempt can be examined here using
+ * syscall_get_error() and syscall_get_return_value(). It is safe
+ * here to call syscall_set_return_value() or syscall_rollback().
+ *
+ * @report_exit:
+ * Requested by %UTRACE_EVENT(%EXIT).
+ * Thread is exiting and cannot be prevented from doing so,
+ * but all its state is still live. The @code value will be
+ * the wait result seen by the parent, and can be changed by
+ * this engine or others. The @orig_code value is the real
+ * status, not changed by any tracing engine. Returning %UTRACE_STOP
+ * here keeps @task stopped before it cleans up its state and dies,
+ * so it can be examined by other processes. When @task is allowed
+ * to run, it will die and get to the @report_death callback.
+ *
+ * @report_death:
+ * Requested by %UTRACE_EVENT(%DEATH).
+ * Thread is really dead now. It might be reaped by its parent at
+ * any time, or self-reap immediately. Though the actual reaping
+ * may happen in parallel, a report_reap() callback will always be
+ * ordered after a report_death() callback.
+ *
+ * @report_reap:
+ * Requested by %UTRACE_EVENT(%REAP).
+ * Called when someone reaps the dead task (parent, init, or self).
+ * This means the parent called wait, or else this was a detached
+ * thread or a process whose parent ignores SIGCHLD.
+ * No more callbacks are made after this one.
+ * The engine is always detached.
+ * There is nothing more a tracing engine can do about this thread.
+ * After this callback, the @engine pointer will become invalid.
+ * The @task pointer may become invalid if get_task_struct() hasn't
+ * been used to keep it alive.
+ * An engine should always request this callback if it stores the
+ * @engine pointer or stores any pointer in @engine->data, so it
+ * can clean up its data structures.
+ * Unlike other callbacks, this can be called from the parent's context
+ * rather than from the traced thread itself--it must not delay the
+ * parent by blocking.
+ */
+struct utrace_engine_ops {
+ u32 (*report_quiesce)(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ unsigned long event);
+ u32 (*report_signal)(u32 action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ struct pt_regs *regs,
+ siginfo_t *info,
+ const struct k_sigaction *orig_ka,
+ struct k_sigaction *return_ka);
+ u32 (*report_clone)(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *parent,
+ unsigned long clone_flags,
+ struct task_struct *child);
+ u32 (*report_jctl)(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ int type, int notify);
+ u32 (*report_exec)(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ const struct linux_binfmt *fmt,
+ const struct linux_binprm *bprm,
+ struct pt_regs *regs);
+ u32 (*report_syscall_entry)(u32 action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ struct pt_regs *regs);
+ u32 (*report_syscall_exit)(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ struct pt_regs *regs);
+ u32 (*report_exit)(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ long orig_code, long *code);
+ u32 (*report_death)(struct utrace_engine *engine,
+ struct task_struct *task,
+ bool group_dead, int signal);
+ void (*report_reap)(struct utrace_engine *engine,
+ struct task_struct *task);
+};
+
+/**
+ * struct utrace_examiner - private state for using utrace_prepare_examine()
+ *
+ * The members of &struct utrace_examiner are private to the implementation.
+ * This data type holds the state from a call to utrace_prepare_examine()
+ * to be used by a call to utrace_finish_examine().
+ */
+struct utrace_examiner {
+/* private: */
+ long state;
+ unsigned long ncsw;
+};
+
+/*
+ * These are the exported entry points for tracing engines to use.
+ * See kernel/utrace.c for their kerneldoc comments with interface details.
+ */
+struct utrace_engine *utrace_attach_task(struct task_struct *, int,
+ const struct utrace_engine_ops *,
+ void *);
+struct utrace_engine *utrace_attach_pid(struct pid *, int,
+ const struct utrace_engine_ops *,
+ void *);
+int __must_check utrace_control(struct task_struct *,
+ struct utrace_engine *,
+ enum utrace_resume_action);
+int __must_check utrace_set_events(struct task_struct *,
+ struct utrace_engine *,
+ unsigned long eventmask);
+int __must_check utrace_barrier(struct task_struct *,
+ struct utrace_engine *);
+int __must_check utrace_prepare_examine(struct task_struct *,
+ struct utrace_engine *,
+ struct utrace_examiner *);
+int __must_check utrace_finish_examine(struct task_struct *,
+ struct utrace_engine *,
+ struct utrace_examiner *);
+
+/**
+ * utrace_control_pid - control a thread being traced by a tracing engine
+ * @pid: thread to affect
+ * @engine: attached engine to affect
+ * @action: &enum utrace_resume_action for thread to do
+ *
+ * This is the same as utrace_control(), but takes a &struct pid
+ * pointer rather than a &struct task_struct pointer. The caller must
+ * hold a ref on @pid, but does not need to worry about the task
+ * staying valid. If it's been reaped so that @pid points nowhere,
+ * then this call returns -%ESRCH.
+ */
+static inline __must_check int utrace_control_pid(
+ struct pid *pid, struct utrace_engine *engine,
+ enum utrace_resume_action action)
+{
+ /*
+ * We don't bother with rcu_read_lock() here to protect the
+ * task_struct pointer, because utrace_control will return
+ * -ESRCH without looking at that pointer if the engine is
+ * already detached. A task_struct pointer can't die before
+ * all the engines are detached in release_task() first.
+ */
+ struct task_struct *task = pid_task(pid, PIDTYPE_PID);
+ return unlikely(!task) ? -ESRCH : utrace_control(task, engine, action);
+}
+
+/**
+ * utrace_set_events_pid - choose which event reports a tracing engine gets
+ * @pid: thread to affect
+ * @engine: attached engine to affect
+ * @eventmask: new event mask
+ *
+ * This is the same as utrace_set_events(), but takes a &struct pid
+ * pointer rather than a &struct task_struct pointer. The caller must
+ * hold a ref on @pid, but does not need to worry about the task
+ * staying valid. If it's been reaped so that @pid points nowhere,
+ * then this call returns -%ESRCH.
+ */
+static inline __must_check int utrace_set_events_pid(
+ struct pid *pid, struct utrace_engine *engine, unsigned long eventmask)
+{
+ struct task_struct *task = pid_task(pid, PIDTYPE_PID);
+ return unlikely(!task) ? -ESRCH :
+ utrace_set_events(task, engine, eventmask);
+}
+
+/**
+ * utrace_barrier_pid - synchronize with simultaneous tracing callbacks
+ * @pid: thread to affect
+ * @engine: engine to affect (can be detached)
+ *
+ * This is the same as utrace_barrier(), but takes a &struct pid
+ * pointer rather than a &struct task_struct pointer. The caller must
+ * hold a ref on @pid, but does not need to worry about the task
+ * staying valid. If it's been reaped so that @pid points nowhere,
+ * then this call returns -%ESRCH.
+ */
+static inline __must_check int utrace_barrier_pid(struct pid *pid,
+ struct utrace_engine *engine)
+{
+ struct task_struct *task = pid_task(pid, PIDTYPE_PID);
+ return unlikely(!task) ? -ESRCH : utrace_barrier(task, engine);
+}
+
+#endif /* CONFIG_UTRACE */
+
+#endif /* linux/utrace.h */
diff --git a/include/linux/utrace_struct.h b/include/linux/utrace_struct.h
new file mode 100644
index ...aba7e09 100644
--- /dev/null
+++ b/include/linux/utrace_struct.h
@@ -0,0 +1,58 @@
+/*
+ * 'struct utrace' data structure for kernel/utrace.c private use.
+ *
+ * Copyright (C) 2006-2009 Red Hat, Inc. All rights reserved.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU General Public License v.2.
+ */
+
+#ifndef _LINUX_UTRACE_STRUCT_H
+#define _LINUX_UTRACE_STRUCT_H 1
+
+#ifdef CONFIG_UTRACE
+
+#include <linux/list.h>
+#include <linux/spinlock.h>
+
+/*
+ * Per-thread structure private to utrace implementation. This properly
+ * belongs in kernel/utrace.c and its use is entirely private to the code
+ * there. It is only defined in a header file so that it can be embedded
+ * in the struct task_struct layout. It is here rather than in utrace.h
+ * to avoid header nesting order issues getting too complex.
+ *
+ */
+struct utrace {
+ struct task_struct *cloning;
+
+ struct list_head attached, attaching;
+ spinlock_t lock;
+
+ struct utrace_engine *reporting;
+
+ unsigned int stopped:1;
+ unsigned int report:1;
+ unsigned int interrupt:1;
+ unsigned int signal_handler:1;
+ unsigned int vfork_stop:1; /* need utrace_stop() before vfork wait */
+ unsigned int death:1; /* in utrace_report_death() now */
+ unsigned int reap:1; /* release_task() has run */
+};
+
+# define INIT_UTRACE(tsk) \
+ .utrace_flags = 0, \
+ .utrace = { \
+ .lock = __SPIN_LOCK_UNLOCKED(tsk.utrace.lock), \
+ .attached = LIST_HEAD_INIT(tsk.utrace.attached), \
+ .attaching = LIST_HEAD_INIT(tsk.utrace.attaching), \
+ },
+
+#else
+
+# define INIT_UTRACE(tsk) /* Nothing. */
+
+#endif /* CONFIG_UTRACE */
+
+#endif /* linux/utrace_struct.h */
diff --git a/init/Kconfig b/init/Kconfig
index 6a5c5fe..4b5ab3e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1060,6 +1060,15 @@ config STOP_MACHINE
help
Need stop_machine() primitive.
+menuconfig UTRACE
+ bool "Infrastructure for tracing and debugging user processes"
+ depends on EXPERIMENTAL
+ depends on HAVE_ARCH_TRACEHOOK
+ help
+ Enable the utrace process tracing interface. This is an internal
+ kernel interface exported to kernel modules, to track events in
+ user threads, extract and change user thread state.
+
source "block/Kconfig"
config PREEMPT_NOTIFIERS
diff --git a/kernel/Makefile b/kernel/Makefile
index e4791b3..7bff724 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_IKCONFIG) += configs.o
obj-$(CONFIG_RESOURCE_COUNTERS) += res_counter.o
obj-$(CONFIG_STOP_MACHINE) += stop_machine.o
obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
+obj-$(CONFIG_UTRACE) += utrace.o
obj-$(CONFIG_AUDIT) += audit.o auditfilter.o
obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c9cf48b..41e9542 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -16,6 +16,7 @@
#include <linux/pagemap.h>
#include <linux/smp_lock.h>
#include <linux/ptrace.h>
+#include <linux/utrace.h>
#include <linux/security.h>
#include <linux/signal.h>
#include <linux/audit.h>
@@ -172,6 +173,14 @@ bool ptrace_may_access(struct task_struc
return (!err ? true : false);
}
+/*
+ * For experimental use of utrace, exclude ptrace on the same task.
+ */
+static inline bool exclude_ptrace(struct task_struct *task)
+{
+ return unlikely(!!task_utrace_flags(task));
+}
+
int ptrace_attach(struct task_struct *task)
{
int retval;
@@ -210,6 +219,11 @@ repeat:
goto repeat;
}
+ if (exclude_ptrace(task)) {
+ retval = -EBUSY;
+ goto bad;
+ }
+
if (!task->mm)
goto bad;
/* the same process cannot be attached many times */
@@ -515,7 +529,9 @@ int ptrace_traceme(void)
*/
repeat:
task_lock(current);
- if (!(current->ptrace & PT_PTRACED)) {
+ if (exclude_ptrace(current)) {
+ ret = -EBUSY;
+ } else if (!(current->ptrace & PT_PTRACED)) {
/*
* See ptrace_attach() comments about the locking here.
*/
diff --git a/kernel/utrace.c b/kernel/utrace.c
new file mode 100644
index ...3af06a6 100644
--- /dev/null
+++ b/kernel/utrace.c
@@ -0,0 +1,2348 @@
+/*
+ * utrace infrastructure interface for debugging user processes
+ *
+ * Copyright (C) 2006-2009 Red Hat, Inc. All rights reserved.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions
+ * of the GNU General Public License v.2.
+ *
+ * Red Hat Author: Roland McGrath.
+ */
+
+#include <linux/utrace.h>
+#include <linux/tracehook.h>
+#include <linux/regset.h>
+#include <asm/syscall.h>
+#include <linux/ptrace.h>
+#include <linux/err.h>
+#include <linux/sched.h>
+#include <linux/freezer.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/seq_file.h>
+
+
+/*
+ * Rules for 'struct utrace', defined in <linux/utrace_struct.h>
+ * but used entirely privately in this file.
+ *
+ * The common event reporting loops are done by the task making the
+ * report without ever taking any locks. To facilitate this, the two
+ * lists @attached and @attaching work together for smooth asynchronous
+ * attaching with low overhead. Modifying either list requires @lock.
+ * The @attaching list can be modified any time while holding @lock.
+ * New engines being attached always go on this list.
+ *
+ * The @attached list is what the task itself uses for its reporting
+ * loops. When the task itself is not quiescent, it can use the
+ * @attached list without taking any lock. Nobody may modify the list
+ * when the task is not quiescent. When it is quiescent, that means
+ * that it won't run again without taking @lock itself before using
+ * the list.
+ *
+ * At each place where we know the task is quiescent (or it's current),
+ * while holding @lock, we call splice_attaching(), below. This moves
+ * the @attaching list members on to the end of the @attached list.
+ * Since this happens at the start of any reporting pass, any new
+ * engines attached asynchronously go on the stable @attached list
+ * in time to have their callbacks seen.
+ */
+
+static struct kmem_cache *utrace_engine_cachep;
+static const struct utrace_engine_ops utrace_detached_ops; /* forward decl */
+
+static int __init utrace_init(void)
+{
+ utrace_engine_cachep = KMEM_CACHE(utrace_engine, SLAB_PANIC);
+ return 0;
+}
+module_init(utrace_init);
+
+/*
+ * This is called with @utrace->lock held when the task is safely
+ * quiescent, i.e. it won't consult utrace->attached without the lock.
+ * Move any engines attached asynchronously from @utrace->attaching
+ * onto the @utrace->attached list.
+ */
+static void splice_attaching(struct utrace *utrace)
+{
+ list_splice_tail_init(&utrace->attaching, &utrace->attached);
+}
+
+/*
+ * This is the exported function used by the utrace_engine_put() inline.
+ */
+void __utrace_engine_release(struct kref *kref)
+{
+ struct utrace_engine *engine = container_of(kref, struct utrace_engine,
+ kref);
+ BUG_ON(!list_empty(&engine->entry));
+ kmem_cache_free(utrace_engine_cachep, engine);
+}
+EXPORT_SYMBOL_GPL(__utrace_engine_release);
+
+static bool engine_matches(struct utrace_engine *engine, int flags,
+ const struct utrace_engine_ops *ops, void *data)
+{
+ if ((flags & UTRACE_ATTACH_MATCH_OPS) && engine->ops != ops)
+ return false;
+ if ((flags & UTRACE_ATTACH_MATCH_DATA) && engine->data != data)
+ return false;
+ return engine->ops && engine->ops != &utrace_detached_ops;
+}
+
+static struct utrace_engine *matching_engine(
+ struct utrace *utrace, int flags,
+ const struct utrace_engine_ops *ops, void *data)
+{
+ struct utrace_engine *engine;
+ list_for_each_entry(engine, &utrace->attached, entry)
+ if (engine_matches(engine, flags, ops, data))
+ return engine;
+ list_for_each_entry(engine, &utrace->attaching, entry)
+ if (engine_matches(engine, flags, ops, data))
+ return engine;
+ return NULL;
+}
+
+/*
+ * For experimental use, utrace attach is mutually exclusive with ptrace.
+ */
+static inline bool exclude_utrace(struct task_struct *task)
+{
+ return unlikely(!!task->ptrace);
+}
+
+/*
+ * Called without locks, when we might be the first utrace engine to attach.
+ * If this is a newborn thread and we are not the creator, we have to wait
+ * for it. The creator gets the first chance to attach. The PF_STARTING
+ * flag is cleared after its report_clone hook has had a chance to run.
+ */
+static inline int utrace_attach_delay(struct task_struct *target)
+{
+ if ((target->flags & PF_STARTING) &&
+ current->utrace.cloning != target)
+ do {
+ schedule_timeout_interruptible(1);
+ if (signal_pending(current))
+ return -ERESTARTNOINTR;
+ } while (target->flags & PF_STARTING);
+
+ return 0;
+}
+
+/*
+ * Enqueue @engine, or maybe don't if UTRACE_ATTACH_EXCLUSIVE.
+ */
+static int utrace_add_engine(struct task_struct *target,
+ struct utrace *utrace,
+ struct utrace_engine *engine,
+ int flags,
+ const struct utrace_engine_ops *ops,
+ void *data)
+{
+ int ret;
+
+ spin_lock(&utrace->lock);
+
+ if (utrace->reap) {
+ /*
+ * Already entered utrace_release_task(), cannot attach now.
+ */
+ ret = -ESRCH;
+ } else if ((flags & UTRACE_ATTACH_EXCLUSIVE) &&
+ unlikely(matching_engine(utrace, flags, ops, data))) {
+ ret = -EEXIST;
+ } else {
+ /*
+ * Put the new engine on the pending ->attaching list.
+ * Make sure it gets onto the ->attached list by the next
+ * time it's examined.
+ *
+ * When target == current, it would be safe just to call
+ * splice_attaching() right here. But if we're inside a
+ * callback, that would mean the new engine also gets
+ * notified about the event that precipitated its own
+ * creation. This is not what the user wants.
+ *
+ * Setting ->report ensures that start_report() takes the
+ * lock and does it next time. Whenever setting ->report,
+ * we must maintain the invariant that TIF_NOTIFY_RESUME is
+ * also set. Otherwise utrace_control() or utrace_do_stop()
+ * might skip setting TIF_NOTIFY_RESUME upon seeing ->report
+ * already set, and we'd miss a necessary callback.
+ *
+ * In case we had no engines before, make sure that
+ * utrace_flags is not zero when tracehook_notify_resume()
+ * checks. That would bypass utrace reporting clearing
+ * TIF_NOTIFY_RESUME, and thus violate the same invariant.
+ */
+ target->utrace_flags |= UTRACE_EVENT(REAP);
+ list_add_tail(&engine->entry, &utrace->attaching);
+ utrace->report = 1;
+ set_notify_resume(target);
+
+ ret = 0;
+ }
+
+ spin_unlock(&utrace->lock);
+
+ return ret;
+}
+
+/**
+ * utrace_attach_task - attach new engine, or look up an attached engine
+ * @target: thread to attach to
+ * @flags: flag bits combined with OR, see below
+ * @ops: callback table for new engine
+ * @data: engine private data pointer
+ *
+ * The caller must ensure that the @target thread does not get freed,
+ * i.e. hold a ref or be its parent. It is always safe to call this
+ * on @current, or on the @child pointer in a @report_clone callback.
+ * For most other cases, it's easier to use utrace_attach_pid() instead.
+ *
+ * UTRACE_ATTACH_CREATE:
+ * Create a new engine. If %UTRACE_ATTACH_CREATE is not specified, you
+ * only look up an existing engine already attached to the thread.
+ *
+ * UTRACE_ATTACH_EXCLUSIVE:
+ * Attempting to attach a second (matching) engine fails with -%EEXIST.
+ *
+ * UTRACE_ATTACH_MATCH_OPS: Only consider engines matching @ops.
+ * UTRACE_ATTACH_MATCH_DATA: Only consider engines matching @data.
+ */
+struct utrace_engine *utrace_attach_task(
+ struct task_struct *target, int flags,
+ const struct utrace_engine_ops *ops, void *data)
+{
+ struct utrace *utrace;
+ struct utrace_engine *engine;
+ int ret;
+
+ utrace = &target->utrace;
+
+ if (unlikely(target->exit_state == EXIT_DEAD)) {
+ /*
+ * The target has already been reaped.
+ * Check this early, though it's not synchronized.
+ * utrace_add_engine() will do the final check.
+ */
+ if (!(flags & UTRACE_ATTACH_CREATE))
+ return ERR_PTR(-ENOENT);
+ return ERR_PTR(-ESRCH);
+ }
+
+ if (!(flags & UTRACE_ATTACH_CREATE)) {
+ spin_lock(&utrace->lock);
+ engine = matching_engine(utrace, flags, ops, data);
+ if (engine)
+ utrace_engine_get(engine);
+ spin_unlock(&utrace->lock);
+ return engine ?: ERR_PTR(-ENOENT);
+ }
+
+ if (unlikely(!ops) || unlikely(ops == &utrace_detached_ops))
+ return ERR_PTR(-EINVAL);
+
+ if (unlikely(target->flags & PF_KTHREAD))
+ /*
+ * Silly kernel, utrace is for users!
+ */
+ return ERR_PTR(-EPERM);
+
+ engine = kmem_cache_alloc(utrace_engine_cachep, GFP_KERNEL);
+ if (unlikely(!engine))
+ return ERR_PTR(-ENOMEM);
+
+ /*
+ * Initialize the new engine structure. It starts out with two
+ * refs: one ref to return, and one ref for being attached.
+ */
+ kref_set(&engine->kref, 2);
+ engine->flags = 0;
+ engine->ops = ops;
+ engine->data = data;
+
+ ret = utrace_attach_delay(target);
+ if (likely(!ret))
+ ret = utrace_add_engine(target, utrace, engine,
+ flags, ops, data);
+
+ if (unlikely(ret)) {
+ kmem_cache_free(utrace_engine_cachep, engine);
+ engine = ERR_PTR(ret);
+ }
+
+ return engine;
+}
+EXPORT_SYMBOL_GPL(utrace_attach_task);
+
+/**
+ * utrace_attach_pid - attach new engine, or look up an attached engine
+ * @pid: &struct pid pointer representing thread to attach to
+ * @flags: flag bits combined with OR, see utrace_attach_task()
+ * @ops: callback table for new engine
+ * @data: engine private data pointer
+ *
+ * This is the same as utrace_attach_task(), but takes a &struct pid
+ * pointer rather than a &struct task_struct pointer. The caller must
+ * hold a ref on @pid, but does not need to worry about the task
+ * staying valid. If it's been reaped so that @pid points nowhere,
+ * then this call returns -%ESRCH.
+ */
+struct utrace_engine *utrace_attach_pid(
+ struct pid *pid, int flags,
+ const struct utrace_engine_ops *ops, void *data)
+{
+ struct utrace_engine *engine = ERR_PTR(-ESRCH);
+ struct task_struct *task = get_pid_task(pid, PIDTYPE_PID);
+ if (task) {
+ engine = utrace_attach_task(task, flags, ops, data);
+ put_task_struct(task);
+ }
+ return engine;
+}
+EXPORT_SYMBOL_GPL(utrace_attach_pid);
+
+/*
+ * When an engine is detached, the target thread may still see it and
+ * make callbacks until it quiesces. We install a special ops vector
+ * with these two callbacks. When the target thread quiesces, it can
+ * safely free the engine itself. For any event we will always get
+ * the report_quiesce() callback first, so we only need this one
+ * pointer to be set. The only exception is report_reap(), so we
+ * supply that callback too.
+ */
+static u32 utrace_detached_quiesce(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ unsigned long event)
+{
+ return UTRACE_DETACH;
+}
+
+static void utrace_detached_reap(struct utrace_engine *engine,
+ struct task_struct *task)
+{
+}
+
+static const struct utrace_engine_ops utrace_detached_ops = {
+ .report_quiesce = &utrace_detached_quiesce,
+ .report_reap = &utrace_detached_reap
+};
+
+/*
+ * After waking up from TASK_TRACED, clear bookkeeping in @utrace.
+ * Returns true if we were woken up prematurely by SIGKILL.
+ */
+static inline bool finish_utrace_stop(struct task_struct *task,
+ struct utrace *utrace)
+{
+ bool killed = false;
+
+ /*
+ * utrace_wakeup() clears @utrace->stopped before waking us up.
+ * We're officially awake if it's clear.
+ */
+ spin_lock(&utrace->lock);
+ if (unlikely(utrace->stopped)) {
+ /*
+ * If we're here with it still set, it must have been
+ * signal_wake_up() instead, waking us up for a SIGKILL.
+ */
+ spin_lock_irq(&task->sighand->siglock);
+ WARN_ON(!sigismember(&task->pending.signal, SIGKILL));
+ spin_unlock_irq(&task->sighand->siglock);
+ utrace->stopped = 0;
+ killed = true;
+ }
+ spin_unlock(&utrace->lock);
+
+ return killed;
+}
+
+/*
+ * Perform %UTRACE_STOP, i.e. block in TASK_TRACED until woken up.
+ * @task == current, @utrace == current->utrace, which is not locked.
+ * Return true if we were woken up by SIGKILL even though some utrace
+ * engine may still want us to stay stopped.
+ */
+static bool utrace_stop(struct task_struct *task, struct utrace *utrace,
+ bool report)
+{
+ bool killed;
+
+ /*
+ * @utrace->stopped is the flag that says we are safely
+ * inside this function. It should never be set on entry.
+ */
+ BUG_ON(utrace->stopped);
+
+ /*
+ * The siglock protects us against signals. As well as SIGKILL
+ * waking us up, we must synchronize with the signal bookkeeping
+ * for stop signals and SIGCONT.
+ */
+ spin_lock(&utrace->lock);
+ spin_lock_irq(&task->sighand->siglock);
+
+ if (unlikely(sigismember(&task->pending.signal, SIGKILL))) {
+ spin_unlock_irq(&task->sighand->siglock);
+ spin_unlock(&utrace->lock);
+ return true;
+ }
+
+ if (report) {
+ /*
+ * Ensure a reporting pass when we're resumed.
+ */
+ utrace->report = 1;
+ set_thread_flag(TIF_NOTIFY_RESUME);
+ }
+
+ utrace->stopped = 1;
+ __set_current_state(TASK_TRACED);
+
+ /*
+ * If there is a group stop in progress,
+ * we must participate in the bookkeeping.
+ */
+ if (task->signal->group_stop_count > 0)
+ --task->signal->group_stop_count;
+
+ spin_unlock_irq(&task->sighand->siglock);
+ spin_unlock(&utrace->lock);
+
+ schedule();
+
+ /*
+ * While in TASK_TRACED, we were considered "frozen enough".
+ * Now that we woke up, it's crucial if we're supposed to be
+ * frozen that we freeze now before running anything substantial.
+ */
+ try_to_freeze();
+
+ killed = finish_utrace_stop(task, utrace);
+
+ /*
+ * While we were in TASK_TRACED, complete_signal() considered
+ * us "uninterested" in signal wakeups. Now make sure our
+ * TIF_SIGPENDING state is correct for normal running.
+ */
+ spin_lock_irq(&task->sighand->siglock);
+ recalc_sigpending();
+ spin_unlock_irq(&task->sighand->siglock);
+
+ return killed;
+}
+
+/*
+ * The caller has to hold a ref on the engine. If the attached flag is
+ * true (all but utrace_barrier() calls), the engine is supposed to be
+ * attached. If the attached flag is false (utrace_barrier() only),
+ * then return -ERESTARTSYS for an engine marked for detach but not yet
+ * fully detached. The task pointer can be invalid if the engine is
+ * detached.
+ *
+ * Get the utrace lock for the target task.
+ * Returns the struct if locked, or ERR_PTR(-errno).
+ *
+ * This has to be robust against races with:
+ * utrace_control(target, UTRACE_DETACH) calls
+ * UTRACE_DETACH after reports
+ * utrace_report_death
+ * utrace_release_task
+ */
+static struct utrace *get_utrace_lock(struct task_struct *target,
+ struct utrace_engine *engine,
+ bool attached)
+ __acquires(utrace->lock)
+{
+ struct utrace *utrace;
+
+ rcu_read_lock();
+
+ /*
+ * If this engine was already detached, bail out before we look at
+ * the task_struct pointer at all. If it's detached after this
+ * check, then RCU is still keeping this task_struct pointer valid.
+ *
+ * The ops pointer is NULL when the engine is fully detached.
+ * It's &utrace_detached_ops when it's marked detached but still
+ * on the list. In the latter case, utrace_barrier() still works,
+ * since the target might be in the middle of an old callback.
+ */
+ if (unlikely(!engine->ops)) {
+ rcu_read_unlock();
+ return ERR_PTR(-ESRCH);
+ }
+
+ if (unlikely(engine->ops == &utrace_detached_ops)) {
+ rcu_read_unlock();
+ return attached ? ERR_PTR(-ESRCH) : ERR_PTR(-ERESTARTSYS);
+ }
+
+ utrace = &target->utrace;
+ if (unlikely(target->exit_state == EXIT_DEAD)) {
+ /*
+ * If all engines detached already, utrace is clear.
+ * Otherwise, we're called after utrace_release_task might
+ * have started. A call to this engine's report_reap
+ * callback might already be in progress.
+ */
+ utrace = ERR_PTR(-ESRCH);
+ } else {
+ spin_lock(&utrace->lock);
+ if (unlikely(!engine->ops) ||
+ unlikely(engine->ops == &utrace_detached_ops)) {
+ /*
+ * By the time we got the utrace lock,
+ * it had been reaped or detached already.
+ */
+ spin_unlock(&utrace->lock);
+ utrace = ERR_PTR(-ESRCH);
+ if (!attached && engine->ops == &utrace_detached_ops)
+ utrace = ERR_PTR(-ERESTARTSYS);
+ }
+ }
+ rcu_read_unlock();
+
+ return utrace;
+}
+
+/*
+ * Now that we don't hold any locks, run through any
+ * detached engines and free their references. Each
+ * engine had one implicit ref while it was attached.
+ */
+static void put_detached_list(struct list_head *list)
+{
+ struct utrace_engine *engine, *next;
+ list_for_each_entry_safe(engine, next, list, entry) {
+ list_del_init(&engine->entry);
+ utrace_engine_put(engine);
+ }
+}
+
+/*
+ * Called with utrace->lock held.
+ * Notify and clean up all engines, then free utrace.
+ */
+static void utrace_reap(struct task_struct *target, struct utrace *utrace)
+ __releases(utrace->lock)
+{
+ struct utrace_engine *engine, *next;
+ const struct utrace_engine_ops *ops;
+ LIST_HEAD(detached);
+
+restart:
+ splice_attaching(utrace);
+ list_for_each_entry_safe(engine, next, &utrace->attached, entry) {
+ ops = engine->ops;
+ engine->ops = NULL;
+ list_move(&engine->entry, &detached);
+
+ /*
+ * If it didn't need a callback, we don't need to drop
+ * the lock. Now nothing else refers to this engine.
+ */
+ if (!(engine->flags & UTRACE_EVENT(REAP)))
+ continue;
+
+ /*
+ * This synchronizes with utrace_barrier(). Since we
+ * need the utrace->lock here anyway (unlike the other
+ * reporting loops), we don't need any memory barrier
+ * as utrace_barrier() holds the lock.
+ */
+ utrace->reporting = engine;
+ spin_unlock(&utrace->lock);
+
+ (*ops->report_reap)(engine, target);
+
+ utrace->reporting = NULL;
+
+ put_detached_list(&detached);
+
+ spin_lock(&utrace->lock);
+ goto restart;
+ }
+
+ spin_unlock(&utrace->lock);
+
+ put_detached_list(&detached);
+}
+
+/*
+ * Called by release_task. After this, target->utrace must be cleared.
+ */
+void utrace_release_task(struct task_struct *target)
+{
+ struct utrace *utrace;
+
+ utrace = &target->utrace;
+
+ spin_lock(&utrace->lock);
+
+ utrace->reap = 1;
+
+ if (!(target->utrace_flags & _UTRACE_DEATH_EVENTS)) {
+ utrace_reap(target, utrace); /* Unlocks and frees. */
+ return;
+ }
+
+ /*
+ * The target will do some final callbacks but hasn't
+ * finished them yet. We know because it clears these
+ * event bits after it's done. Instead of cleaning up here
+ * and requiring utrace_report_death to cope with it, we
+ * delay the REAP report and the teardown until after the
+ * target finishes its death reports.
+ */
+
+ spin_unlock(&utrace->lock);
+}
+
+/*
+ * We use an extra bit in utrace_engine.flags past the event bits,
+ * to record whether the engine is keeping the target thread stopped.
+ */
+#define ENGINE_STOP (1UL << _UTRACE_NEVENTS)
+
+static void mark_engine_wants_stop(struct utrace_engine *engine)
+{
+ engine->flags |= ENGINE_STOP;
+}
+
+static void clear_engine_wants_stop(struct utrace_engine *engine)
+{
+ engine->flags &= ~ENGINE_STOP;
+}
+
+static bool engine_wants_stop(struct utrace_engine *engine)
+{
+ return (engine->flags & ENGINE_STOP) != 0;
+}
+
+/**
+ * utrace_set_events - choose which event reports a tracing engine gets
+ * @target: thread to affect
+ * @engine: attached engine to affect
+ * @events: new event mask
+ *
+ * This changes the set of events for which @engine wants callbacks made.
+ *
+ * This fails with -%EALREADY and does nothing if you try to clear
+ * %UTRACE_EVENT(%DEATH) when the @report_death callback may already have
+ * begun, if you try to clear %UTRACE_EVENT(%REAP) when the @report_reap
+ * callback may already have begun, or if you try to newly set
+ * %UTRACE_EVENT(%DEATH) or %UTRACE_EVENT(%QUIESCE) when @target is
+ * already dead or dying.
+ *
+ * This can fail with -%ESRCH when @target has already been detached,
+ * including forcible detach on reaping.
+ *
+ * If @target was stopped before the call, then after a successful call,
+ * no event callbacks not requested in @events will be made; if
+ * %UTRACE_EVENT(%QUIESCE) is included in @events, then a @report_quiesce
+ * callback will be made when @target resumes. If @target was not stopped,
+ * and was about to make a callback to @engine, this returns -%EINPROGRESS.
+ * In this case, the callback in progress might be one excluded from the
+ * new @events setting. When this returns zero, you can be sure that no
+ * event callbacks you've disabled in @events can be made.
+ *
+ * To synchronize after an -%EINPROGRESS return, see utrace_barrier().
+ *
+ * When @target is @current, -%EINPROGRESS is not returned. But
+ * note that a newly-created engine will not receive any callbacks
+ * related to an event notification already in progress. This call
+ * enables @events callbacks to be made as soon as @engine becomes
+ * eligible for any callbacks, see utrace_attach_task().
+ *
+ * These rules provide for coherent synchronization based on %UTRACE_STOP,
+ * even when %SIGKILL is breaking its normal simple rules.
+ */
+int utrace_set_events(struct task_struct *target,
+ struct utrace_engine *engine,
+ unsigned long events)
+{
+ struct utrace *utrace;
+ unsigned long old_flags, old_utrace_flags, set_utrace_flags;
+ int ret;
+
+ utrace = get_utrace_lock(target, engine, true);
+ if (unlikely(IS_ERR(utrace)))
+ return PTR_ERR(utrace);
+
+ old_utrace_flags = target->utrace_flags;
+ set_utrace_flags = events;
+ old_flags = engine->flags;
+
+ if (target->exit_state &&
+ (((events & ~old_flags) & _UTRACE_DEATH_EVENTS) ||
+ (utrace->death &&
+ ((old_flags & ~events) & _UTRACE_DEATH_EVENTS)) ||
+ (utrace->reap && ((old_flags & ~events) & UTRACE_EVENT(REAP))))) {
+ spin_unlock(&utrace->lock);
+ return -EALREADY;
+ }
+
+ /*
+ * When setting these flags, it's essential that we really
+ * synchronize with exit_notify(). They cannot be set after
+ * exit_notify() takes the tasklist_lock. By holding the read
+ * lock here while setting the flags, we ensure that the calls
+ * to tracehook_notify_death() and tracehook_report_death() will
+ * see the new flags. This ensures that utrace_release_task()
+ * knows positively that utrace_report_death() will be called or
+ * that it won't.
+ */
+ if ((set_utrace_flags & ~old_utrace_flags) & _UTRACE_DEATH_EVENTS) {
+ read_lock(&tasklist_lock);
+ if (unlikely(target->exit_state)) {
+ read_unlock(&tasklist_lock);
+ spin_unlock(&utrace->lock);
+ return -EALREADY;
+ }
+ target->utrace_flags |= set_utrace_flags;
+ read_unlock(&tasklist_lock);
+ }
+
+ engine->flags = events | (engine->flags & ENGINE_STOP);
+ target->utrace_flags |= set_utrace_flags;
+
+ if ((set_utrace_flags & UTRACE_EVENT_SYSCALL) &&
+ !(old_utrace_flags & UTRACE_EVENT_SYSCALL))
+ set_tsk_thread_flag(target, TIF_SYSCALL_TRACE);
+
+ ret = 0;
+ if (!utrace->stopped && target != current) {
+ /*
+ * This barrier ensures that our engine->flags changes
+ * have hit before we examine utrace->reporting,
+ * pairing with the barrier in start_callback(). If
+ * @target has not yet hit finish_callback() to clear
+ * utrace->reporting, we might be in the middle of a
+ * callback to @engine.
+ */
+ smp_mb();
+ if (utrace->reporting == engine)
+ ret = -EINPROGRESS;
+ }
+
+ spin_unlock(&utrace->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(utrace_set_events);
+
+/*
+ * Asynchronously mark an engine as being detached.
+ *
+ * This must work while the target thread races with us doing
+ * start_callback(), defined below. It uses smp_rmb() between checking
+ * @engine->flags and using @engine->ops. Here we change @engine->ops
+ * first, then use smp_wmb() before changing @engine->flags. This ensures
+ * it can check the old flags before using the old ops, or check the old
+ * flags before using the new ops, or check the new flags before using the
+ * new ops, but can never check the new flags before using the old ops.
+ * Hence, utrace_detached_ops might be used with any old flags in place.
+ * It has report_quiesce() and report_reap() callbacks to handle all cases.
+ */
+static void mark_engine_detached(struct utrace_engine *engine)
+{
+ engine->ops = &utrace_detached_ops;
+ smp_wmb();
+ engine->flags = UTRACE_EVENT(QUIESCE);
+}
+
+/*
+ * Get @target to stop and return true if it is already stopped now.
+ * If we return false, it will make some event callback soonish.
+ * Called with @utrace locked.
+ */
+static bool utrace_do_stop(struct task_struct *target, struct utrace *utrace)
+{
+ bool stopped = false;
+
+ spin_lock_irq(&target->sighand->siglock);
+ if (unlikely(target->exit_state)) {
+ /*
+ * On the exit path, it's only truly quiescent
+ * if it has already been through
+ * utrace_report_death(), or never will.
+ */
+ if (!(target->utrace_flags & _UTRACE_DEATH_EVENTS))
+ utrace->stopped = stopped = true;
+ } else if (task_is_stopped(target)) {
+ /*
+ * Stopped is considered quiescent; when it wakes up, it will
+ * go through utrace_get_signal() before doing anything else.
+ */
+ utrace->stopped = stopped = true;
+ } else if (!utrace->report && !utrace->interrupt) {
+ utrace->report = 1;
+ set_notify_resume(target);
+ }
+ spin_unlock_irq(&target->sighand->siglock);
+
+ return stopped;
+}
+
+/*
+ * If the target is not dead it should not be in tracing
+ * stop any more. Wake it unless it's in job control stop.
+ *
+ * Called with @utrace->lock held and @utrace->stopped set.
+ */
+static void utrace_wakeup(struct task_struct *target, struct utrace *utrace)
+{
+ struct sighand_struct *sighand;
+ unsigned long irqflags;
+
+ utrace->stopped = 0;
+
+ sighand = lock_task_sighand(target, &irqflags);
+ if (unlikely(!sighand))
+ return;
+
+ if (likely(task_is_stopped_or_traced(target))) {
+ if (target->signal->flags & SIGNAL_STOP_STOPPED)
+ target->state = TASK_STOPPED;
+ else
+ wake_up_state(target, __TASK_STOPPED | __TASK_TRACED);
+ }
+
+ unlock_task_sighand(target, &irqflags);
+}
+
+/*
+ * This is called when there might be some detached engines on the list or
+ * some stale bits in @task->utrace_flags. Clean them up and recompute the
+ * flags.
+ *
+ * @action is NULL when @task is stopped and @utrace->stopped is set; wake
+ * it up if it should not be. @action is set when @task is current; if
+ * we're fully detached, reset *@action to UTRACE_RESUME.
+ *
+ * Called with @utrace->lock held, returns with it released.
+ * After this returns, @utrace might be freed if everything detached.
+ */
+static void utrace_reset(struct task_struct *task, struct utrace *utrace,
+ enum utrace_resume_action *action)
+ __releases(utrace->lock)
+{
+ struct utrace_engine *engine, *next;
+ unsigned long flags = 0;
+ LIST_HEAD(detached);
+ bool wake = !action;
+ BUG_ON(wake != (task != current));
+
+ splice_attaching(utrace);
+
+ /*
+ * Update the set of events of interest from the union
+ * of the interests of the remaining tracing engines.
+ * For any engine marked detached, remove it from the list.
+ * We'll collect them on the detached list.
+ */
+ list_for_each_entry_safe(engine, next, &utrace->attached, entry) {
+ if (engine->ops == &utrace_detached_ops) {
+ engine->ops = NULL;
+ list_move(&engine->entry, &detached);
+ } else {
+ flags |= engine->flags | UTRACE_EVENT(REAP);
+ wake = wake && !engine_wants_stop(engine);
+ }
+ }
+
+ if (task->exit_state) {
+ /*
+ * Once it's already dead, we never install any flags
+ * except REAP. When ->exit_state is set and events
+ * like DEATH are not set, then they never can be set.
+ * This ensures that utrace_release_task() knows
+ * positively that utrace_report_death() can never run.
+ */
+ BUG_ON(utrace->death);
+ flags &= UTRACE_EVENT(REAP);
+ wake = false;
+ } else if (!(flags & UTRACE_EVENT_SYSCALL) &&
+ test_tsk_thread_flag(task, TIF_SYSCALL_TRACE)) {
+ clear_tsk_thread_flag(task, TIF_SYSCALL_TRACE);
+ }
+
+ task->utrace_flags = flags;
+
+ if (wake)
+ utrace_wakeup(task, utrace);
+
+ /*
+ * If any engines are left, we're done.
+ */
+ spin_unlock(&utrace->lock);
+ if (!flags) {
+ /*
+ * No more engines, cleared out the utrace.
+ */
+
+ if (action)
+ *action = UTRACE_RESUME;
+ }
+
+ put_detached_list(&detached);
+}
+
+/*
+ * You can't do anything to a dead task but detach it.
+ * If release_task() has been called, you can't do that.
+ *
+ * On the exit path, DEATH and QUIESCE event bits are set only
+ * before utrace_report_death() has taken the lock. At that point,
+ * the death report will come soon, so disallow detach until it's
+ * done. This prevents us from racing with it detaching itself.
+ *
+ * Called with utrace->lock held, when @target->exit_state is nonzero.
+ */
+static inline int utrace_control_dead(struct task_struct *target,
+ struct utrace *utrace,
+ enum utrace_resume_action action)
+{
+ if (action != UTRACE_DETACH || unlikely(utrace->reap))
+ return -ESRCH;
+
+ if (unlikely(utrace->death))
+ /*
+ * We have already started the death report. We can't
+ * prevent the report_death and report_reap callbacks,
+ * so tell the caller they will happen.
+ */
+ return -EALREADY;
+
+ return 0;
+}
+
+/**
+ * utrace_control - control a thread being traced by a tracing engine
+ * @target: thread to affect
+ * @engine: attached engine to affect
+ * @action: &enum utrace_resume_action for thread to do
+ *
+ * This is how a tracing engine asks a traced thread to do something.
+ * This call is controlled by the @action argument, which has the
+ * same meaning as the &enum utrace_resume_action value returned by
+ * event reporting callbacks.
+ *
+ * If @target is already dead (@target->exit_state nonzero),
+ * all actions except %UTRACE_DETACH fail with -%ESRCH.
+ *
+ * The following sections describe each option for the @action argument.
+ *
+ * UTRACE_DETACH:
+ *
+ * After this, the @engine data structure is no longer accessible,
+ * and the thread might be reaped. The thread will start running
+ * again if it was stopped and no longer has any attached engines
+ * that want it stopped.
+ *
+ * If the @report_reap callback may already have begun, this fails
+ * with -%ESRCH. If the @report_death callback may already have
+ * begun, this fails with -%EALREADY.
+ *
+ * If @target is not already stopped, then a callback to this engine
+ * might be in progress or about to start on another CPU. If so,
+ * then this returns -%EINPROGRESS; the detach happens as soon as
+ * the pending callback is finished. To synchronize after an
+ * -%EINPROGRESS return, see utrace_barrier().
+ *
+ * If @target is properly stopped before utrace_control() is called,
+ * then after successful return it's guaranteed that no more callbacks
+ * to the @engine->ops vector will be made.
+ *
+ * The only exception is %SIGKILL (and exec or group-exit by another
+ * thread in the group), which can cause asynchronous @report_death
+ * and/or @report_reap callbacks even when %UTRACE_STOP was used.
+ * (In that event, this fails with -%ESRCH or -%EALREADY, see above.)
+ *
+ * UTRACE_STOP:
+ * This asks that @target stop running. This returns 0 only if
+ * @target is already stopped, either for tracing or for job
+ * control. Then @target will remain stopped until another
+ * utrace_control() call is made on @engine; @target can be woken
+ * only by %SIGKILL (or equivalent, such as exec or termination by
+ * another thread in the same thread group).
+ *
+ * This returns -%EINPROGRESS if @target is not already stopped.
+ * Then the effect is like %UTRACE_REPORT. A @report_quiesce or
+ * @report_signal callback will be made soon. Your callback can
+ * then return %UTRACE_STOP to keep @target stopped.
+ *
+ * This does not interrupt system calls in progress, including ones
+ * that sleep for a long time. For that, use %UTRACE_INTERRUPT.
+ * To interrupt system calls and then keep @target stopped, your
+ * @report_signal callback can return %UTRACE_STOP.
+ *
+ * UTRACE_RESUME:
+ *
+ * Just let @target continue running normally, reversing the effect
+ * of a previous %UTRACE_STOP. If another engine is keeping @target
+ * stopped, then it remains stopped until all engines let it resume.
+ * If @target was not stopped, this has no effect.
+ *
+ * UTRACE_REPORT:
+ *
+ * This is like %UTRACE_RESUME, but also ensures that there will be
+ * a @report_quiesce or @report_signal callback made soon. If
+ * @target had been stopped, then there will be a callback before it
+ * resumes running normally. If another engine is keeping @target
+ * stopped, then there might be no callbacks until all engines let
+ * it resume.
+ *
+ * UTRACE_INTERRUPT:
+ *
+ * This is like %UTRACE_REPORT, but ensures that @target will make a
+ * @report_signal callback before it resumes or delivers signals.
+ * If @target was in a system call or about to enter one, work in
+ * progress will be interrupted as if by %SIGSTOP. If another
+ * engine is keeping @target stopped, then there might be no
+ * callbacks until all engines let it resume.
+ *
+ * This gives @engine an opportunity to introduce a forced signal
+ * disposition via its @report_signal callback.
+ *
+ * UTRACE_SINGLESTEP:
+ *
+ * It's invalid to use this unless arch_has_single_step() returned true.
+ * This is like %UTRACE_RESUME, but resumes for one user instruction
+ * only. It's invalid to use this in utrace_control() unless @target
+ * had been stopped by @engine previously.
+ *
+ * Note that passing %UTRACE_SINGLESTEP or %UTRACE_BLOCKSTEP to
+ * utrace_control() or returning it from an event callback alone does
+ * not necessarily ensure that stepping will be enabled. If there are
+ * more callbacks made to any engine before returning to user mode,
+ * then the resume action is chosen only by the last set of callbacks.
+ * To be sure, enable %UTRACE_EVENT(%QUIESCE) and look for the
+ * @report_quiesce callback with a zero event mask, or the
+ * @report_signal callback with %UTRACE_SIGNAL_REPORT.
+ *
+ * UTRACE_BLOCKSTEP:
+ *
+ * It's invalid to use this unless arch_has_block_step() returned true.
+ * This is like %UTRACE_SINGLESTEP, but resumes for one whole basic
+ * block of user instructions.
+ *
+ * %UTRACE_BLOCKSTEP devolves to %UTRACE_SINGLESTEP when another
+ * tracing engine is using %UTRACE_SINGLESTEP at the same time.
+ */
+int utrace_control(struct task_struct *target,
+ struct utrace_engine *engine,
+ enum utrace_resume_action action)
+{
+ struct utrace *utrace;
+ bool resume;
+ int ret;
+
+ if (unlikely(action > UTRACE_DETACH))
+ return -EINVAL;
+
+ utrace = get_utrace_lock(target, engine, true);
+ if (unlikely(IS_ERR(utrace)))
+ return PTR_ERR(utrace);
+
+ if (target->exit_state) {
+ ret = utrace_control_dead(target, utrace, action);
+ if (ret) {
+ spin_unlock(&utrace->lock);
+ return ret;
+ }
+ }
+
+ resume = utrace->stopped;
+ ret = 0;
+
+ clear_engine_wants_stop(engine);
+ switch (action) {
+ case UTRACE_STOP:
+ mark_engine_wants_stop(engine);
+ if (!resume && !utrace_do_stop(target, utrace))
+ ret = -EINPROGRESS;
+ resume = false;
+ break;
+
+ case UTRACE_DETACH:
+ mark_engine_detached(engine);
+ resume = resume || utrace_do_stop(target, utrace);
+ if (!resume) {
+ /*
+ * As in utrace_set_events(), this barrier ensures
+ * that our engine->flags changes have hit before we
+ * examine utrace->reporting, pairing with the barrier
+ * in start_callback(). If @target has not yet hit
+ * finish_callback() to clear utrace->reporting, we
+ * might be in the middle of a callback to @engine.
+ */
+ smp_mb();
+ if (utrace->reporting == engine)
+ ret = -EINPROGRESS;
+ break;
+ }
+ /* Fall through. */
+
+ case UTRACE_RESUME:
+ /*
+ * This and all other cases imply resuming if stopped.
+ * There might not be another report before it just
+ * resumes, so make sure single-step is not left set.
+ */
+ if (likely(resume))
+ user_disable_single_step(target);
+ break;
+
+ case UTRACE_REPORT:
+ /*
+ * Make the thread call tracehook_notify_resume() soon.
+ * But don't bother if it's already been interrupted.
+ * In that case, utrace_get_signal() will be reporting soon.
+ */
+ if (!utrace->report && !utrace->interrupt) {
+ utrace->report = 1;
+ set_notify_resume(target);
+ }
+ break;
+
+ case UTRACE_INTERRUPT:
+ /*
+ * Make the thread call tracehook_get_signal() soon.
+ */
+ if (utrace->interrupt)
+ break;
+ utrace->interrupt = 1;
+
+ /*
+ * If it's not already stopped, interrupt it now.
+ * We need the siglock here in case it calls
+ * recalc_sigpending() and clears its own
+ * TIF_SIGPENDING. By taking the lock, we've
+ * serialized any later recalc_sigpending() after
+ * our setting of utrace->interrupt to force it on.
+ */
+ if (resume) {
+ /*
+ * This is really just to keep the invariant
+ * that TIF_SIGPENDING is set with utrace->interrupt.
+ * When it's stopped, we know it's always going
+ * through utrace_get_signal and will recalculate.
+ */
+ set_tsk_thread_flag(target, TIF_SIGPENDING);
+ } else {
+ struct sighand_struct *sighand;
+ unsigned long irqflags;
+ sighand = lock_task_sighand(target, &irqflags);
+ if (likely(sighand)) {
+ signal_wake_up(target, 0);
+ unlock_task_sighand(target, &irqflags);
+ }
+ }
+ break;
+
+ case UTRACE_BLOCKSTEP:
+ /*
+ * Resume from stopped, step one block.
+ */
+ if (unlikely(!arch_has_block_step())) {
+ WARN_ON(1);
+ /* Fall through to treat it as SINGLESTEP. */
+ } else if (likely(resume)) {
+ user_enable_block_step(target);
+ break;
+ }
+
+ case UTRACE_SINGLESTEP:
+ /*
+ * Resume from stopped, step one instruction.
+ */
+ if (unlikely(!arch_has_single_step())) {
+ WARN_ON(1);
+ resume = false;
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
+ if (likely(resume))
+ user_enable_single_step(target);
+ else
+ /*
+ * You were supposed to stop it before asking
+ * it to step.
+ */
+ ret = -EAGAIN;
+ break;
+ }
+
+ /*
+ * Let the thread resume running. If it's not stopped now,
+ * there is nothing more we need to do.
+ */
+ if (resume)
+ utrace_reset(target, utrace, NULL);
+ else
+ spin_unlock(&utrace->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(utrace_control);
+
+/**
+ * utrace_barrier - synchronize with simultaneous tracing callbacks
+ * @target: thread to affect
+ * @engine: engine to affect (can be detached)
+ *
+ * This blocks while @target might be in the midst of making a callback to
+ * @engine. It can be interrupted by signals and will return -%ERESTARTSYS.
+ * A return value of zero means no callback from @target to @engine was
+ * in progress. Any effect of its return value (such as %UTRACE_STOP) has
+ * already been applied to @engine.
+ *
+ * It's not necessary to keep the @target pointer alive for this call.
+ * It's only necessary to hold a ref on @engine. This will return
+ * safely even if @target has been reaped and has no task refs.
+ *
+ * A successful return from utrace_barrier() guarantees its ordering
+ * with respect to utrace_set_events() and utrace_control() calls. If
+ * @target was not properly stopped, event callbacks just disabled might
+ * still be in progress; utrace_barrier() waits until there is no chance
+ * an unwanted callback can be in progress.
+ */
+int utrace_barrier(struct task_struct *target, struct utrace_engine *engine)
+{
+ struct utrace *utrace;
+ int ret = -ERESTARTSYS;
+
+ if (unlikely(target == current))
+ return 0;
+
+ do {
+ utrace = get_utrace_lock(target, engine, false);
+ if (unlikely(IS_ERR(utrace))) {
+ ret = PTR_ERR(utrace);
+ if (ret != -ERESTARTSYS)
+ break;
+ } else {
+ /*
+ * All engine state changes are done while
+ * holding the lock, i.e. before we get here.
+ * Since we have the lock, we only need to
+ * worry about @target making a callback.
+ * When it has entered start_callback() but
+ * not yet gotten to finish_callback(), we
+ * will see utrace->reporting == @engine.
+ * When @target doesn't take the lock, it uses
+ * barriers to order setting utrace->reporting
+ * before it examines the engine state.
+ */
+ if (utrace->reporting != engine)
+ ret = 0;
+ spin_unlock(&utrace->lock);
+ if (!ret)
+ break;
+ }
+ schedule_timeout_interruptible(1);
+ } while (!signal_pending(current));
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(utrace_barrier);
+
+/*
+ * This is local state used for reporting loops, perhaps optimized away.
+ */
+struct utrace_report {
+ enum utrace_resume_action action;
+ u32 result;
+ bool detaches;
+ bool reports;
+ bool takers;
+ bool killed;
+};
+
+#define INIT_REPORT(var) \
+ struct utrace_report var = { UTRACE_RESUME, 0, \
+ false, false, false, false }
+
+/*
+ * We are now making the report, so clear the flag saying we need one.
+ */
+static void start_report(struct utrace *utrace)
+{
+ BUG_ON(utrace->stopped);
+ if (utrace->report) {
+ spin_lock(&utrace->lock);
+ utrace->report = 0;
+ splice_attaching(utrace);
+ spin_unlock(&utrace->lock);
+ }
+}
+
+/*
+ * Complete a normal reporting pass, pairing with a start_report() call.
+ * This handles any UTRACE_DETACH or UTRACE_REPORT or UTRACE_INTERRUPT
+ * returns from engine callbacks. If any engine's last callback used
+ * UTRACE_STOP, we do UTRACE_REPORT here to ensure we stop before user
+ * mode. If there were no callbacks made, it will recompute
+ * @task->utrace_flags to avoid another false-positive.
+ */
+static void finish_report(struct utrace_report *report,
+ struct task_struct *task, struct utrace *utrace)
+{
+ bool clean = (report->takers && !report->detaches);
+
+ if (report->action <= UTRACE_REPORT && !utrace->report) {
+ spin_lock(&utrace->lock);
+ utrace->report = 1;
+ set_tsk_thread_flag(task, TIF_NOTIFY_RESUME);
+ } else if (report->action == UTRACE_INTERRUPT && !utrace->interrupt) {
+ spin_lock(&utrace->lock);
+ utrace->interrupt = 1;
+ set_tsk_thread_flag(task, TIF_SIGPENDING);
+ } else if (clean) {
+ return;
+ } else {
+ spin_lock(&utrace->lock);
+ }
+
+ if (clean)
+ spin_unlock(&utrace->lock);
+ else
+ utrace_reset(task, utrace, &report->action);
+}
+
+/*
+ * Apply the return value of one engine callback to @report.
+ * Returns true if @engine detached and should not get any more callbacks.
+ */
+static bool finish_callback(struct utrace *utrace,
+ struct utrace_report *report,
+ struct utrace_engine *engine,
+ u32 ret)
+{
+ enum utrace_resume_action action = utrace_resume_action(ret);
+
+ report->result = ret & ~UTRACE_RESUME_MASK;
+
+ /*
+ * If utrace_control() was used, treat that like UTRACE_DETACH here.
+ */
+ if (action == UTRACE_DETACH || engine->ops == &utrace_detached_ops) {
+ engine->ops = &utrace_detached_ops;
+ report->detaches = true;
+ } else {
+ if (action < report->action)
+ report->action = action;
+
+ if (action == UTRACE_STOP) {
+ if (!engine_wants_stop(engine)) {
+ spin_lock(&utrace->lock);
+ mark_engine_wants_stop(engine);
+ spin_unlock(&utrace->lock);
+ }
+ } else {
+ if (action == UTRACE_REPORT)
+ report->reports = true;
+
+ if (engine_wants_stop(engine)) {
+ spin_lock(&utrace->lock);
+ clear_engine_wants_stop(engine);
+ spin_unlock(&utrace->lock);
+ }
+ }
+ }
+
+ /*
+ * Now that we have applied the effect of the return value,
+ * clear this so that utrace_barrier() can stop waiting.
+ * A subsequent utrace_control() can stop or resume @engine
+ * and know this was ordered after its callback's action.
+ *
+ * We don't need any barriers here because utrace_barrier()
+ * takes utrace->lock. If we touched engine->flags above,
+ * the lock guaranteed this change was before utrace_barrier()
+ * examined utrace->reporting.
+ */
+ utrace->reporting = NULL;
+
+ /*
+ * This is a good place to make sure tracing engines don't
+ * introduce too much latency under voluntary preemption.
+ */
+ if (need_resched())
+ cond_resched();
+
+ return engine->ops == &utrace_detached_ops;
+}
+
+/*
+ * Start the callbacks for @engine to consider @event (a bit mask).
+ * This makes the report_quiesce() callback first. If @engine wants
+ * a specific callback for @event, we return the ops vector to use.
+ * If not, we return NULL. The return value from the ops->callback
+ * function called should be passed to finish_callback().
+ */
+static const struct utrace_engine_ops *start_callback(
+ struct utrace *utrace, struct utrace_report *report,
+ struct utrace_engine *engine, struct task_struct *task,
+ unsigned long event)
+{
+ const struct utrace_engine_ops *ops;
+ unsigned long want;
+
+ /*
+ * This barrier ensures that we've set utrace->reporting before
+ * we examine engine->flags or engine->ops. utrace_barrier()
+ * relies on this ordering to indicate that the effect of any
+ * utrace_control() and utrace_set_events() calls is in place
+ * by the time utrace->reporting can be seen to be NULL.
+ */
+ utrace->reporting = engine;
+ smp_mb();
+
+ /*
+ * This pairs with the barrier in mark_engine_detached().
+ * It makes sure that we never see the old ops vector with
+ * the new flags, in case the original vector had no report_quiesce.
+ */
+ want = engine->flags;
+ smp_rmb();
+ ops = engine->ops;
+
+ if (want & UTRACE_EVENT(QUIESCE)) {
+ if (finish_callback(utrace, report, engine,
+ (*ops->report_quiesce)(report->action,
+ engine, task,
+ event)))
+ return NULL;
+
+ /*
+ * finish_callback() reset utrace->reporting after the
+ * quiesce callback. Now we set it again (as above)
+ * before re-examining engine->flags, which could have
+ * been changed synchronously by ->report_quiesce or
+ * asynchronously by utrace_control() or utrace_set_events().
+ */
+ utrace->reporting = engine;
+ smp_mb();
+ want = engine->flags;
+ }
+
+ if (want & ENGINE_STOP)
+ report->action = UTRACE_STOP;
+
+ if (want & event) {
+ report->takers = true;
+ return ops;
+ }
+
+ return NULL;
+}
+
+/*
+ * Do a normal reporting pass for engines interested in @event.
+ * @callback is the name of the member in the ops vector, and remaining
+ * args are the extras it takes after the standard three args.
+ */
+#define REPORT(task, utrace, report, event, callback, ...) \
+ do { \
+ start_report(utrace); \
+ REPORT_CALLBACKS(task, utrace, report, event, callback, \
+ (report)->action, engine, current, \
+ ## __VA_ARGS__); \
+ finish_report(report, task, utrace); \
+ } while (0)
+#define REPORT_CALLBACKS(task, utrace, report, event, callback, ...) \
+ do { \
+ struct utrace_engine *engine; \
+ const struct utrace_engine_ops *ops; \
+ list_for_each_entry(engine, &utrace->attached, entry) { \
+ ops = start_callback(utrace, report, engine, task, \
+ event); \
+ if (!ops) \
+ continue; \
+ finish_callback(utrace, report, engine, \
+ (*ops->callback)(__VA_ARGS__)); \
+ } \
+ } while (0)
+
+/*
+ * Called iff UTRACE_EVENT(EXEC) flag is set.
+ */
+void utrace_report_exec(struct linux_binfmt *fmt, struct linux_binprm *bprm,
+ struct pt_regs *regs)
+{
+ struct task_struct *task = current;
+ struct utrace *utrace = task_utrace_struct(task);
+ INIT_REPORT(report);
+
+ REPORT(task, utrace, &report, UTRACE_EVENT(EXEC),
+ report_exec, fmt, bprm, regs);
+}
+
+/*
+ * Called iff UTRACE_EVENT(SYSCALL_ENTRY) flag is set.
+ * Return true to prevent the system call.
+ */
+bool utrace_report_syscall_entry(struct pt_regs *regs)
+{
+ struct task_struct *task = current;
+ struct utrace *utrace = task_utrace_struct(task);
+ INIT_REPORT(report);
+
+ start_report(utrace);
+ REPORT_CALLBACKS(task, utrace, &report, UTRACE_EVENT(SYSCALL_ENTRY),
+ report_syscall_entry, report.result | report.action,
+ engine, current, regs);
+ finish_report(&report, task, utrace);
+
+ if (report.action == UTRACE_STOP &&
+ unlikely(utrace_stop(task, utrace, false)))
+ /*
+ * We are continuing despite UTRACE_STOP because of a
+ * SIGKILL. Don't let the system call actually proceed.
+ */
+ return true;
+
+ if (unlikely(report.result == UTRACE_SYSCALL_ABORT))
+ return true;
+
+ if (signal_pending(task)) {
+ /*
+ * Clear TIF_SIGPENDING if it no longer needs to be set.
+ * It may have been set as part of quiescence, and won't
+ * ever have been cleared by another thread. For other
+ * reports, we can just leave it set and will go through
+ * utrace_get_signal() to reset things. But here we are
+ * about to enter a syscall, which might bail out with an
+ * -ERESTART* error if it's set now.
+ */
+ spin_lock_irq(&task->sighand->siglock);
+ recalc_sigpending();
+ spin_unlock_irq(&task->sighand->siglock);
+ }
+
+ return false;
+}
+
+/*
+ * Called iff UTRACE_EVENT(SYSCALL_EXIT) flag is set.
+ */
+void utrace_report_syscall_exit(struct pt_regs *regs)
+{
+ struct task_struct *task = current;
+ struct utrace *utrace = task_utrace_struct(task);
+ INIT_REPORT(report);
+
+ REPORT(task, utrace, &report, UTRACE_EVENT(SYSCALL_EXIT),
+ report_syscall_exit, regs);
+}
+
+/*
+ * Called iff UTRACE_EVENT(CLONE) flag is set.
+ * This notification call blocks the wake_up_new_task call on the child.
+ * So we must not quiesce here. tracehook_report_clone_complete will do
+ * a quiescence check momentarily.
+ */
+void utrace_report_clone(unsigned long clone_flags, struct task_struct *child)
+{
+ struct task_struct *task = current;
+ struct utrace *utrace = task_utrace_struct(task);
+ INIT_REPORT(report);
+
+ /*
+ * We don't use the REPORT() macro here, because we need
+ * to clear utrace->cloning before finish_report().
+ * After finish_report(), utrace can be a stale pointer
+ * in cases when report.action is still UTRACE_RESUME.
+ */
+ start_report(utrace);
+ utrace->cloning = child;
+
+ REPORT_CALLBACKS(task, utrace, &report,
+ UTRACE_EVENT(CLONE), report_clone,
+ report.action, engine, task, clone_flags, child);
+
+ utrace->cloning = NULL;
+ finish_report(&report, task, utrace);
+
+ /*
+ * For a vfork, we will go into an uninterruptible block waiting
+ * for the child. We need UTRACE_STOP to happen before this, not
+ * after. For CLONE_VFORK, utrace_finish_vfork() will be called.
+ */
+ if (report.action == UTRACE_STOP && (clone_flags & CLONE_VFORK)) {
+ spin_lock(&utrace->lock);
+ utrace->vfork_stop = 1;
+ spin_unlock(&utrace->lock);
+ }
+}
+
+/*
+ * We're called after utrace_report_clone() for a CLONE_VFORK.
+ * If UTRACE_STOP was left from the clone report, we stop here.
+ * After this, we'll enter the uninterruptible wait_for_completion()
+ * waiting for the child.
+ */
+void utrace_finish_vfork(struct task_struct *task)
+{
+ struct utrace *utrace = task_utrace_struct(task);
+
+ spin_lock(&utrace->lock);
+ if (!utrace->vfork_stop)
+ spin_unlock(&utrace->lock);
+ else {
+ utrace->vfork_stop = 0;
+ spin_unlock(&utrace->lock);
+ utrace_stop(task, utrace, false);
+ }
+}
+
+/*
+ * Called iff UTRACE_EVENT(JCTL) flag is set.
+ *
+ * Called with siglock held.
+ */
+void utrace_report_jctl(int notify, int what)
+{
+ struct task_struct *task = current;
+ struct utrace *utrace = task_utrace_struct(task);
+ INIT_REPORT(report);
+ bool stop = task_is_stopped(task);
+
+ /*
+ * We have to come out of TASK_STOPPED in case the event report
+ * hooks might block. Since we held the siglock throughout, it's
+ * as if we were never in TASK_STOPPED yet at all.
+ */
+ if (stop) {
+ __set_current_state(TASK_RUNNING);
+ task->signal->flags &= ~SIGNAL_STOP_STOPPED;
+ ++task->signal->group_stop_count;
+ }
+ spin_unlock_irq(&task->sighand->siglock);
+
+ /*
+ * We get here with CLD_STOPPED when we've just entered
+ * TASK_STOPPED, or with CLD_CONTINUED when we've just come
+ * out but not yet been through utrace_get_signal() again.
+ *
+ * While in TASK_STOPPED, we can be considered safely
+ * stopped by utrace_do_stop() and detached asynchronously.
+ * If we woke up and checked task->utrace_flags before that
+ * was finished, we might be here with utrace already
+ * removed or in the middle of being removed.
+ *
+ * If we are indeed attached, then make sure we are no
+ * longer considered stopped while we run callbacks.
+ */
+ spin_lock(&utrace->lock);
+ utrace->stopped = 0;
+ /*
+ * Do start_report()'s work too since we already have the lock anyway.
+ */
+ utrace->report = 0;
+ splice_attaching(utrace);
+ spin_unlock(&utrace->lock);
+
+ REPORT(task, utrace, &report, UTRACE_EVENT(JCTL),
+ report_jctl, what, notify);
+
+ /*
+ * Retake the lock, and go back into TASK_STOPPED
+ * unless the stop was just cleared.
+ */
+ spin_lock_irq(&task->sighand->siglock);
+ if (stop && task->signal->group_stop_count > 0) {
+ __set_current_state(TASK_STOPPED);
+ if (--task->signal->group_stop_count == 0)
+ task->signal->flags |= SIGNAL_STOP_STOPPED;
+ }
+}
+
+/*
+ * Called iff UTRACE_EVENT(EXIT) flag is set.
+ */
+void utrace_report_exit(long *exit_code)
+{
+ struct task_struct *task = current;
+ struct utrace *utrace = task_utrace_struct(task);
+ INIT_REPORT(report);
+ long orig_code = *exit_code;
+
+ REPORT(task, utrace, &report, UTRACE_EVENT(EXIT),
+ report_exit, orig_code, exit_code);
+
+ if (report.action == UTRACE_STOP)
+ utrace_stop(task, utrace, false);
+}
+
+/*
+ * Called iff UTRACE_EVENT(DEATH) or UTRACE_EVENT(QUIESCE) flag is set.
+ *
+ * It is always possible that we are racing with utrace_release_task here.
+ * For this reason, utrace_release_task checks for the event bits that get
+ * us here, and delays its cleanup for us to do.
+ */
+void utrace_report_death(struct task_struct *task, struct utrace *utrace,
+ bool group_dead, int signal)
+{
+ INIT_REPORT(report);
+
+ BUG_ON(!task->exit_state);
+
+ /*
+ * We are presently considered "quiescent"--which is accurate
+ * inasmuch as we won't run any more user instructions ever again.
+ * But for utrace_control and utrace_set_events to be robust, they
+ * must be sure whether or not we will run any more callbacks. If
+ * a call comes in before we do, taking the lock here synchronizes
+ * us so we don't run any callbacks just disabled. Calls that come
+ * in while we're running the callbacks will see the exit.death
+ * flag and know that we are not yet fully quiescent for purposes
+ * of detach bookkeeping.
+ */
+ spin_lock(&utrace->lock);
+ BUG_ON(utrace->death);
+ utrace->death = 1;
+ utrace->report = 0;
+ utrace->interrupt = 0;
+ spin_unlock(&utrace->lock);
+
+ REPORT_CALLBACKS(task, utrace, &report, UTRACE_EVENT(DEATH),
+ report_death, engine, task, group_dead, signal);
+
+ spin_lock(&utrace->lock);
+
+ /*
+ * After we unlock (possibly inside utrace_reap for callbacks) with
+ * this flag clear, competing utrace_control/utrace_set_events calls
+ * know that we've finished our callbacks and any detach bookkeeping.
+ */
+ utrace->death = 0;
+
+ if (utrace->reap)
+ /*
+ * utrace_release_task() was already called in parallel.
+ * We must complete its work now.
+ */
+ utrace_reap(task, utrace);
+ else
+ utrace_reset(task, utrace, &report.action);
+}
+
+/*
+ * Finish the last reporting pass before returning to user mode.
+ */
+static void finish_resume_report(struct utrace_report *report,
+ struct task_struct *task,
+ struct utrace *utrace)
+{
+ if (report->detaches || !report->takers) {
+ spin_lock(&utrace->lock);
+ utrace_reset(task, utrace, &report->action);
+ }
+
+ switch (report->action) {
+ case UTRACE_STOP:
+ report->killed = utrace_stop(task, utrace, report->reports);
+ break;
+
+ case UTRACE_INTERRUPT:
+ if (!signal_pending(task))
+ set_tsk_thread_flag(task, TIF_SIGPENDING);
+ break;
+
+ case UTRACE_SINGLESTEP:
+ user_enable_single_step(task);
+ break;
+
+ case UTRACE_BLOCKSTEP:
+ user_enable_block_step(task);
+ break;
+
+ case UTRACE_REPORT:
+ case UTRACE_RESUME:
+ default:
+ user_disable_single_step(task);
+ break;
+ }
+}
+
+/*
+ * This is called when TIF_NOTIFY_RESUME had been set (and is now clear).
+ * We are close to user mode, and this is the place to report or stop.
+ * When we return, we're going to user mode or into the signals code.
+ */
+void utrace_resume(struct task_struct *task, struct pt_regs *regs)
+{
+ struct utrace *utrace = task_utrace_struct(task);
+ INIT_REPORT(report);
+ struct utrace_engine *engine;
+
+ /*
+ * Some machines get here with interrupts disabled. The same arch
+ * code path leads to calling into get_signal_to_deliver(), which
+ * implicitly reenables them by virtue of spin_unlock_irq.
+ */
+ local_irq_enable();
+
+ /*
+ * If this flag is still set it's because there was a signal
+ * handler setup done but no report_signal following it. Clear
+ * the flag before we get to user so it doesn't confuse us later.
+ */
+ if (unlikely(utrace->signal_handler)) {
+ int skip;
+ spin_lock(&utrace->lock);
+ utrace->signal_handler = 0;
+ skip = !utrace->report;
+ spin_unlock(&utrace->lock);
+ if (skip)
+ return;
+ }
+
+ /*
+ * If UTRACE_INTERRUPT was just used, we don't bother with a
+ * report here. We will report and stop in utrace_get_signal().
+ */
+ if (unlikely(utrace->interrupt))
+ return;
+
+ /*
+ * Do a simple reporting pass, with no callback after report_quiesce.
+ */
+ start_report(utrace);
+
+ list_for_each_entry(engine, &utrace->attached, entry)
+ start_callback(utrace, &report, engine, task, 0);
+
+ /*
+ * Finish the report and either stop or get ready to resume.
+ */
+ finish_resume_report(&report, task, utrace);
+}
+
+/*
+ * Return true if current has forced signal_pending().
+ *
+ * This is called only when current->utrace_flags is nonzero, so we know
+ * that current->utrace must be set. It's not inlined in tracehook.h
+ * just so that struct utrace can stay opaque outside this file.
+ */
+bool utrace_interrupt_pending(void)
+{
+ return task_utrace_struct(current)->interrupt;
+}
+
+/*
+ * Take the siglock and push @info back on our queue.
+ * Returns with @task->sighand->siglock held.
+ */
+static void push_back_signal(struct task_struct *task, siginfo_t *info)
+ __acquires(task->sighand->siglock)
+{
+ struct sigqueue *q;
+
+ if (unlikely(!info->si_signo)) { /* Oh, a wise guy! */
+ spin_lock_irq(&task->sighand->siglock);
+ return;
+ }
+
+ q = sigqueue_alloc();
+ if (likely(q)) {
+ q->flags = 0;
+ copy_siginfo(&q->info, info);
+ }
+
+ spin_lock_irq(&task->sighand->siglock);
+
+ sigaddset(&task->pending.signal, info->si_signo);
+ if (likely(q))
+ list_add(&q->list, &task->pending.list);
+
+ set_tsk_thread_flag(task, TIF_SIGPENDING);
+}
+
+/*
+ * This is the hook from the signals code, called with the siglock held.
+ * Here is the ideal place to stop. We also dequeue and intercept signals.
+ */
+int utrace_get_signal(struct task_struct *task, struct pt_regs *regs,
+ siginfo_t *info, struct k_sigaction *return_ka)
+ __releases(task->sighand->siglock)
+ __acquires(task->sighand->siglock)
+{
+ struct utrace *utrace;
+ struct k_sigaction *ka;
+ INIT_REPORT(report);
+ struct utrace_engine *engine;
+ const struct utrace_engine_ops *ops;
+ unsigned long event, want;
+ u32 ret;
+ int signr;
+
+ utrace = &task->utrace;
+ if (utrace->interrupt || utrace->report || utrace->signal_handler) {
+ /*
+ * We've been asked for an explicit report before we
+ * even check for pending signals.
+ */
+
+ spin_unlock_irq(&task->sighand->siglock);
+
+ spin_lock(&utrace->lock);
+
+ splice_attaching(utrace);
+
+ if (unlikely(!utrace->interrupt) && unlikely(!utrace->report))
+ report.result = UTRACE_SIGNAL_IGN;
+ else if (utrace->signal_handler)
+ report.result = UTRACE_SIGNAL_HANDLER;
+ else
+ report.result = UTRACE_SIGNAL_REPORT;
+
+ /*
+ * We are now making the report and it's on the
+ * interrupt path, so clear the flags asking for those.
+ */
+ utrace->interrupt = utrace->report = utrace->signal_handler = 0;
+ utrace->stopped = 0;
+
+ /*
+ * Make sure signal_pending() only returns true
+ * if there are real signals pending.
+ */
+ if (signal_pending(task)) {
+ spin_lock_irq(&task->sighand->siglock);
+ recalc_sigpending();
+ spin_unlock_irq(&task->sighand->siglock);
+ }
+
+ spin_unlock(&utrace->lock);
+
+ if (unlikely(report.result == UTRACE_SIGNAL_IGN))
+ /*
+ * We only got here to clear utrace->signal_handler.
+ */
+ return -1;
+
+ /*
+ * Do a reporting pass for no signal, just for EVENT(QUIESCE).
+ * The engine callbacks can fill in *info and *return_ka.
+ * We'll pass NULL for the @orig_ka argument to indicate
+ * that there was no original signal.
+ */
+ event = 0;
+ ka = NULL;
+ memset(return_ka, 0, sizeof *return_ka);
+ } else if ((task->utrace_flags & UTRACE_EVENT_SIGNAL_ALL) == 0 &&
+ !utrace->stopped) {
+ /*
+ * If no engine is interested in intercepting signals,
+ * let the caller just dequeue them normally.
+ */
+ return 0;
+ } else {
+ if (unlikely(utrace->stopped)) {
+ spin_unlock_irq(&task->sighand->siglock);
+ spin_lock(&utrace->lock);
+ utrace->stopped = 0;
+ spin_unlock(&utrace->lock);
+ spin_lock_irq(&task->sighand->siglock);
+ }
+
+ /*
+ * Steal the next signal so we can let tracing engines
+ * examine it. From the signal number and sigaction,
+ * determine what normal delivery would do. If no
+ * engine perturbs it, we'll do that by returning the
+ * signal number after setting *return_ka.
+ */
+ signr = dequeue_signal(task, &task->blocked, info);
+ if (signr == 0)
+ return signr;
+ BUG_ON(signr != info->si_signo);
+
+ ka = &task->sighand->action[signr - 1];
+ *return_ka = *ka;
+
+ /*
+ * We are never allowed to interfere with SIGKILL.
+ * Just punt after filling in *return_ka for our caller.
+ */
+ if (signr == SIGKILL)
+ return signr;
+
+ if (ka->sa.sa_handler == SIG_IGN) {
+ event = UTRACE_EVENT(SIGNAL_IGN);
+ report.result = UTRACE_SIGNAL_IGN;
+ } else if (ka->sa.sa_handler != SIG_DFL) {
+ event = UTRACE_EVENT(SIGNAL);
+ report.result = UTRACE_SIGNAL_DELIVER;
+ } else if (sig_kernel_coredump(signr)) {
+ event = UTRACE_EVENT(SIGNAL_CORE);
+ report.result = UTRACE_SIGNAL_CORE;
+ } else if (sig_kernel_ignore(signr)) {
+ event = UTRACE_EVENT(SIGNAL_IGN);
+ report.result = UTRACE_SIGNAL_IGN;
+ } else if (signr == SIGSTOP) {
+ event = UTRACE_EVENT(SIGNAL_STOP);
+ report.result = UTRACE_SIGNAL_STOP;
+ } else if (sig_kernel_stop(signr)) {
+ event = UTRACE_EVENT(SIGNAL_STOP);
+ report.result = UTRACE_SIGNAL_TSTP;
+ } else {
+ event = UTRACE_EVENT(SIGNAL_TERM);
+ report.result = UTRACE_SIGNAL_TERM;
+ }
+
+ /*
+ * Now that we know what event type this signal is, we
+ * can short-circuit if no engines care about those.
+ */
+ if ((task->utrace_flags & (event | UTRACE_EVENT(QUIESCE))) == 0)
+ return signr;
+
+ /*
+ * We have some interested engines, so tell them about
+ * the signal and let them change its disposition.
+ */
+ spin_unlock_irq(&task->sighand->siglock);
+ }
+
+ /*
+ * This reporting pass chooses what signal disposition we'll act on.
+ */
+ list_for_each_entry(engine, &utrace->attached, entry) {
+ /*
+ * See start_callback() comment about this barrier.
+ */
+ utrace->reporting = engine;
+ smp_mb();
+
+ /*
+ * This pairs with the barrier in mark_engine_detached(),
+ * see start_callback() comments.
+ */
+ want = engine->flags;
+ smp_rmb();
+ ops = engine->ops;
+
+ if ((want & (event | UTRACE_EVENT(QUIESCE))) == 0) {
+ utrace->reporting = NULL;
+ continue;
+ }
+
+ if (ops->report_signal)
+ ret = (*ops->report_signal)(
+ report.result | report.action, engine, task,
+ regs, info, ka, return_ka);
+ else
+ ret = (report.result | (*ops->report_quiesce)(
+ report.action, engine, task, event));
+
+ /*
+ * Avoid a tight loop reporting again and again if some
+ * engine is too stupid.
+ */
+ switch (utrace_resume_action(ret)) {
+ default:
+ break;
+ case UTRACE_INTERRUPT:
+ case UTRACE_REPORT:
+ ret = (ret & ~UTRACE_RESUME_MASK) | UTRACE_RESUME;
+ break;
+ }
+
+ finish_callback(utrace, &report, engine, ret);
+ }
+
+ /*
+ * We express the chosen action to the signals code in terms
+ * of a representative signal whose default action does it.
+ * Our caller uses our return value (signr) to decide what to
+ * do, but uses info->si_signo as the signal number to report.
+ */
+ switch (utrace_signal_action(report.result)) {
+ case UTRACE_SIGNAL_TERM:
+ signr = SIGTERM;
+ break;
+
+ case UTRACE_SIGNAL_CORE:
+ signr = SIGQUIT;
+ break;
+
+ case UTRACE_SIGNAL_STOP:
+ signr = SIGSTOP;
+ break;
+
+ case UTRACE_SIGNAL_TSTP:
+ signr = SIGTSTP;
+ break;
+
+ case UTRACE_SIGNAL_DELIVER:
+ signr = info->si_signo;
+
+ if (return_ka->sa.sa_handler == SIG_DFL) {
+ /*
+ * We'll do signr's normal default action.
+ * For ignore, we'll fall through below.
+ * For stop/death, break locks and returns it.
+ */
+ if (likely(signr) && !sig_kernel_ignore(signr))
+ break;
+ } else if (return_ka->sa.sa_handler != SIG_IGN &&
+ likely(signr)) {
+ /*
+ * Complete the bookkeeping after the report.
+ * The handler will run. If an engine wanted to
+ * stop or step, then make sure we do another
+ * report after signal handler setup.
+ */
+ if (report.action != UTRACE_RESUME)
+ report.action = UTRACE_INTERRUPT;
+ finish_report(&report, task, utrace);
+
+ if (unlikely(report.result & UTRACE_SIGNAL_HOLD))
+ push_back_signal(task, info);
+ else
+ spin_lock_irq(&task->sighand->siglock);
+
+ /*
+ * We do the SA_ONESHOT work here since the
+ * normal path will only touch *return_ka now.
+ */
+ if (unlikely(return_ka->sa.sa_flags & SA_ONESHOT)) {
+ return_ka->sa.sa_flags &= ~SA_ONESHOT;
+ if (likely(valid_signal(signr))) {
+ ka = &task->sighand->action[signr - 1];
+ ka->sa.sa_handler = SIG_DFL;
+ }
+ }
+
+ return signr;
+ }
+
+ /* Fall through for an ignored signal. */
+
+ case UTRACE_SIGNAL_IGN:
+ case UTRACE_SIGNAL_REPORT:
+ default:
+ /*
+ * If the signal is being ignored, then we are on the way
+ * directly back to user mode. We can stop here, or step,
+ * as in utrace_resume(), above. After we've dealt with that,
+ * our caller will relock and come back through here.
+ */
+ finish_resume_report(&report, task, utrace);
+
+ if (unlikely(report.killed)) {
+ /*
+ * The only reason we woke up now was because of a
+ * SIGKILL. Don't do normal dequeuing in case it
+ * might get a signal other than SIGKILL. That would
+ * perturb the death state so it might differ from
+ * what the debugger would have allowed to happen.
+ * Instead, pluck out just the SIGKILL to be sure
+ * we'll die immediately with nothing else different
+ * from the quiescent state the debugger wanted us in.
+ */
+ sigset_t sigkill_only;
+ siginitsetinv(&sigkill_only, sigmask(SIGKILL));
+ spin_lock_irq(&task->sighand->siglock);
+ signr = dequeue_signal(task, &sigkill_only, info);
+ BUG_ON(signr != SIGKILL);
+ *return_ka = task->sighand->action[SIGKILL - 1];
+ return signr;
+ }
+
+ if (unlikely(report.result & UTRACE_SIGNAL_HOLD)) {
+ push_back_signal(task, info);
+ spin_unlock_irq(&task->sighand->siglock);
+ }
+
+ return -1;
+ }
+
+ /*
+ * Complete the bookkeeping after the report.
+ * This sets utrace->report if UTRACE_STOP was used.
+ */
+ finish_report(&report, task, utrace);
+
+ return_ka->sa.sa_handler = SIG_DFL;
+
+ if (unlikely(report.result & UTRACE_SIGNAL_HOLD))
+ push_back_signal(task, info);
+ else
+ spin_lock_irq(&task->sighand->siglock);
+
+ if (sig_kernel_stop(signr))
+ task->signal->flags |= SIGNAL_STOP_DEQUEUED;
+
+ return signr;
+}
+
+/*
+ * This gets called after a signal handler has been set up.
+ * We set a flag so the next report knows it happened.
+ * If we're already stepping, make sure we do a report_signal.
+ * If not, make sure we get into utrace_resume() where we can
+ * clear the signal_handler flag before resuming.
+ */
+void utrace_signal_handler(struct task_struct *task, int stepping)
+{
+ struct utrace *utrace = task_utrace_struct(task);
+
+ spin_lock(&utrace->lock);
+
+ utrace->signal_handler = 1;
+ if (stepping) {
+ utrace->interrupt = 1;
+ set_tsk_thread_flag(task, TIF_SIGPENDING);
+ } else {
+ set_tsk_thread_flag(task, TIF_NOTIFY_RESUME);
+ }
+
+ spin_unlock(&utrace->lock);
+}
+
+/**
+ * utrace_prepare_examine - prepare to examine thread state
+ * @target: thread of interest, a &struct task_struct pointer
+ * @engine: engine pointer returned by utrace_attach_task()
+ * @exam: temporary state, a &struct utrace_examiner pointer
+ *
+ * This call prepares to safely examine the thread @target using
+ * &struct user_regset calls, or direct access to thread-synchronous fields.
+ *
+ * When @target is current, this call is superfluous. When @target is
+ * another thread, it must held stopped via %UTRACE_STOP by @engine.
+ *
+ * This call may block the caller until @target stays stopped, so it must
+ * be called only after the caller is sure @target is about to unschedule.
+ * This means a zero return from a utrace_control() call on @engine giving
+ * %UTRACE_STOP, or a report_quiesce() or report_signal() callback to
+ * @engine that used %UTRACE_STOP in its return value.
+ *
+ * Returns -%ESRCH if @target is dead or -%EINVAL if %UTRACE_STOP was
+ * not used. If @target has started running again despite %UTRACE_STOP
+ * (for %SIGKILL or a spurious wakeup), this call returns -%EAGAIN.
+ *
+ * When this call returns zero, it's safe to use &struct user_regset
+ * calls and task_user_regset_view() on @target and to examine some of
+ * its fields directly. When the examination is complete, a
+ * utrace_finish_examine() call must follow to check whether it was
+ * completed safely.
+ */
+int utrace_prepare_examine(struct task_struct *target,
+ struct utrace_engine *engine,
+ struct utrace_examiner *exam)
+{
+ int ret = 0;
+
+ if (unlikely(target == current))
+ return 0;
+
+ rcu_read_lock();
+ if (unlikely(!engine_wants_stop(engine)))
+ ret = -EINVAL;
+ else if (unlikely(target->exit_state))
+ ret = -ESRCH;
+ else {
+ exam->state = target->state;
+ if (unlikely(exam->state == TASK_RUNNING))
+ ret = -EAGAIN;
+ else
+ get_task_struct(target);
+ }
+ rcu_read_unlock();
+
+ if (likely(!ret)) {
+ exam->ncsw = wait_task_inactive(target, exam->state);
+ put_task_struct(target);
+ if (unlikely(!exam->ncsw))
+ ret = -EAGAIN;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(utrace_prepare_examine);
+
+/**
+ * utrace_finish_examine - complete an examination of thread state
+ * @target: thread of interest, a &struct task_struct pointer
+ * @engine: engine pointer returned by utrace_attach_task()
+ * @exam: pointer passed to utrace_prepare_examine() call
+ *
+ * This call completes an examination on the thread @target begun by a
+ * paired utrace_prepare_examine() call with the same arguments that
+ * returned success (zero).
+ *
+ * When @target is current, this call is superfluous. When @target is
+ * another thread, this returns zero if @target has remained unscheduled
+ * since the paired utrace_prepare_examine() call returned zero.
+ *
+ * When this returns an error, any examination done since the paired
+ * utrace_prepare_examine() call is unreliable and the data extracted
+ * should be discarded. The error is -%EINVAL if @engine is not
+ * keeping @target stopped, or -%EAGAIN if @target woke up unexpectedly.
+ */
+int utrace_finish_examine(struct task_struct *target,
+ struct utrace_engine *engine,
+ struct utrace_examiner *exam)
+{
+ int ret = 0;
+
+ if (unlikely(target == current))
+ return 0;
+
+ rcu_read_lock();
+ if (unlikely(!engine_wants_stop(engine)))
+ ret = -EINVAL;
+ else if (unlikely(target->state != exam->state))
+ ret = -EAGAIN;
+ else
+ get_task_struct(target);
+ rcu_read_unlock();
+
+ if (likely(!ret)) {
+ unsigned long ncsw = wait_task_inactive(target, exam->state);
+ if (unlikely(ncsw != exam->ncsw))
+ ret = -EAGAIN;
+ put_task_struct(target);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(utrace_finish_examine);
+
+/*
+ * This is declared in linux/regset.h and defined in machine-dependent
+ * code. We put the export here to ensure no machine forgets it.
+ */
+EXPORT_SYMBOL_GPL(task_user_regset_view);
+
+/*
+ * Called with rcu_read_lock() held.
+ */
+void task_utrace_proc_status(struct seq_file *m, struct task_struct *p)
+{
+ struct utrace *utrace = &p->utrace;
+ seq_printf(m, "Utrace: %lx%s%s%s\n",
+ p->utrace_flags,
+ utrace->stopped ? " (stopped)" : "",
+ utrace->report ? " (report)" : "",
+ utrace->interrupt ? " (interrupt)" : "");
+}
^ permalink raw reply related [flat|nested] 53+ messages in thread
* [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 1:39 [PATCH 0/3] utrace Roland McGrath
2009-03-21 1:41 ` [PATCH 1/3] signals: tracehook_notify_jctl change Roland McGrath
2009-03-21 1:41 ` [PATCH 2/3] utrace core Roland McGrath
@ 2009-03-21 1:42 ` Roland McGrath
2009-03-21 7:43 ` Ingo Molnar
2 siblings, 1 reply; 53+ messages in thread
From: Roland McGrath @ 2009-03-21 1:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Frank Eigler, utrace-devel, linux-kernel
From: Frank Ch. Eigler <fche@redhat.com>
This is v2 of the prototype utrace-ftrace interface. This code is
based on Roland McGrath's utrace API, which provides programmatic
hooks to the in-tree tracehook layer. This new patch interfaces many
of those events to ftrace, as configured by a small number of debugfs
controls. Here's the /debugfs/tracing/process_trace_README:
process event tracer mini-HOWTO
1. Select process hierarchy to monitor. Other processes will be
completely unaffected. Leave at 0 for system-wide tracing.
% echo NNN > process_follow_pid
2. Determine which process event traces are potentially desired.
syscall and signal tracing slow down monitored processes.
% echo 0 > process_trace_{syscalls,signals,lifecycle}
3. Add any final uid- or taskcomm-based filtering. Non-matching
processes will skip trace messages, but will still be slowed.
% echo NNN > process_trace_uid_filter # -1: unrestricted
% echo ls > process_trace_taskcomm_filter # empty: unrestricted
4. Start tracing.
% echo process > current_tracer
5. Examine trace.
% cat trace
6. Stop tracing.
% echo nop > current_tracer
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
---
include/linux/processtrace.h | 41 +++
kernel/trace/Kconfig | 9 +
kernel/trace/Makefile | 1 +
kernel/trace/trace.h | 8 +
kernel/trace/trace_process.c | 601 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 660 insertions(+), 0 deletions(-)
diff --git a/include/linux/processtrace.h b/include/linux/processtrace.h
new file mode 100644
index ...f2b7d94 100644
--- /dev/null
+++ b/include/linux/processtrace.h
@@ -0,0 +1,41 @@
+#ifndef PROCESSTRACE_H
+#define PROCESSTRACE_H
+
+#include <linux/types.h>
+#include <linux/list.h>
+
+struct process_trace_entry {
+ unsigned char opcode; /* one of _UTRACE_EVENT_* */
+ char comm[TASK_COMM_LEN]; /* XXX: should be in/via trace_entry */
+ union {
+ struct {
+ pid_t child;
+ unsigned long flags;
+ } trace_clone;
+ struct {
+ long code;
+ } trace_exit;
+ struct {
+ } trace_exec;
+ struct {
+ int si_signo;
+ int si_errno;
+ int si_code;
+ } trace_signal;
+ struct {
+ long callno;
+ unsigned long args[6];
+ } trace_syscall_entry;
+ struct {
+ long rc;
+ long error;
+ } trace_syscall_exit;
+ };
+};
+
+/* in kernel/trace/trace_process.c */
+
+extern void enable_process_trace(void);
+extern void disable_process_trace(void);
+
+#endif /* PROCESSTRACE_H */
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 34e707e..8a92d6f 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -150,6 +150,15 @@ config CONTEXT_SWITCH_TRACER
This tracer gets called from the context switch and records
all switching of tasks.
+config PROCESS_TRACER
+ bool "Trace process events via utrace"
+ depends on DEBUG_KERNEL
+ select TRACING
+ select UTRACE
+ help
+ This tracer provides trace records from process events
+ accessible to utrace: lifecycle, system calls, and signals.
+
config BOOT_TRACER
bool "Trace boot initcalls"
depends on DEBUG_KERNEL
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 349d5a9..a774db2 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -33,5 +33,6 @@ obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += t
obj-$(CONFIG_TRACE_BRANCH_PROFILING) += trace_branch.o
obj-$(CONFIG_HW_BRANCH_TRACER) += trace_hw_branches.o
obj-$(CONFIG_POWER_TRACER) += trace_power.o
+obj-$(CONFIG_PROCESS_TRACER) += trace_process.o
libftrace-y := ftrace.o
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 4d3d381..c4d2e7f 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -7,6 +7,7 @@
#include <linux/clocksource.h>
#include <linux/ring_buffer.h>
#include <linux/mmiotrace.h>
+#include <linux/processtrace.h>
#include <linux/ftrace.h>
#include <trace/boot.h>
@@ -30,6 +31,7 @@ enum trace_type {
TRACE_USER_STACK,
TRACE_HW_BRANCHES,
TRACE_POWER,
+ TRACE_PROCESS,
__TRACE_LAST_TYPE
};
@@ -170,6 +172,11 @@ struct trace_power {
struct power_trace state_data;
};
+struct trace_process {
+ struct trace_entry ent;
+ struct process_trace_entry event;
+};
+
/*
* trace_flag_type is an enumeration that holds different
* states when a trace occurs. These are:
@@ -280,6 +287,7 @@ extern void __ftrace_bad_type(void);
TRACE_GRAPH_RET); \
IF_ASSIGN(var, ent, struct hw_branch_entry, TRACE_HW_BRANCHES);\
IF_ASSIGN(var, ent, struct trace_power, TRACE_POWER); \
+ IF_ASSIGN(var, ent, struct trace_process, TRACE_PROCESS); \
__ftrace_bad_type(); \
} while (0)
diff --git a/kernel/trace/trace_process.c b/kernel/trace/trace_process.c
new file mode 100644
index ...0820e56 100644
--- /dev/null
+++ b/kernel/trace/trace_process.c
@@ -0,0 +1,601 @@
+/*
+ * utrace-based process event tracing
+ * Copyright (C) 2009 Red Hat Inc.
+ * By Frank Ch. Eigler <fche@redhat.com>
+ *
+ * Based on mmio ftrace engine by Pekka Paalanen
+ * and utrace-syscall-tracing prototype by Ananth Mavinakayanahalli
+ */
+
+/* #define DEBUG 1 */
+
+#include <linux/kernel.h>
+#include <linux/utrace.h>
+#include <linux/uaccess.h>
+#include <linux/debugfs.h>
+#include <asm/syscall.h>
+
+#include "trace.h"
+
+/* A process must match these filters in order to be traced. */
+static char trace_taskcomm_filter[TASK_COMM_LEN]; /* \0: unrestricted */
+static u32 trace_taskuid_filter = -1; /* -1: unrestricted */
+static u32 trace_lifecycle_p = 1;
+static u32 trace_syscalls_p = 1;
+static u32 trace_signals_p = 1;
+
+/* A process must be a direct child of given pid in order to be
+ followed. */
+static u32 process_follow_pid; /* 0: unrestricted/systemwide */
+
+/* XXX: lock the above? */
+
+
+/* trace data collection */
+
+static struct trace_array *process_trace_array;
+
+static void process_reset_data(struct trace_array *tr)
+{
+ pr_debug("in %s\n", __func__);
+ tracing_reset_online_cpus(tr);
+}
+
+static int process_trace_init(struct trace_array *tr)
+{
+ pr_debug("in %s\n", __func__);
+ process_trace_array = tr;
+ process_reset_data(tr);
+ enable_process_trace();
+ return 0;
+}
+
+static void process_trace_reset(struct trace_array *tr)
+{
+ pr_debug("in %s\n", __func__);
+ disable_process_trace();
+ process_reset_data(tr);
+ process_trace_array = NULL;
+}
+
+static void process_trace_start(struct trace_array *tr)
+{
+ pr_debug("in %s\n", __func__);
+ process_reset_data(tr);
+}
+
+static void __trace_processtrace(struct trace_array *tr,
+ struct trace_array_cpu *data,
+ struct process_trace_entry *ent)
+{
+ struct ring_buffer_event *event;
+ struct trace_process *entry;
+ unsigned long irq_flags;
+
+ event = ring_buffer_lock_reserve(tr->buffer, sizeof(*entry),
+ &irq_flags);
+ if (!event)
+ return;
+ entry = ring_buffer_event_data(event);
+ tracing_generic_entry_update(&entry->ent, 0, preempt_count());
+ entry->ent.cpu = raw_smp_processor_id();
+ entry->ent.type = TRACE_PROCESS;
+ strlcpy(ent->comm, current->comm, TASK_COMM_LEN);
+ entry->event = *ent;
+ ring_buffer_unlock_commit(tr->buffer, event, irq_flags);
+
+ trace_wake_up();
+}
+
+void process_trace(struct process_trace_entry *ent)
+{
+ struct trace_array *tr = process_trace_array;
+ struct trace_array_cpu *data;
+
+ preempt_disable();
+ data = tr->data[smp_processor_id()];
+ __trace_processtrace(tr, data, ent);
+ preempt_enable();
+}
+
+
+/* trace data rendering */
+
+static void process_pipe_open(struct trace_iterator *iter)
+{
+ struct trace_seq *s = &iter->seq;
+ pr_debug("in %s\n", __func__);
+ trace_seq_printf(s, "VERSION 200901\n");
+}
+
+static void process_close(struct trace_iterator *iter)
+{
+ iter->private = NULL;
+}
+
+static ssize_t process_read(struct trace_iterator *iter, struct file *filp,
+ char __user *ubuf, size_t cnt, loff_t *ppos)
+{
+ ssize_t ret;
+ struct trace_seq *s = &iter->seq;
+ ret = trace_seq_to_user(s, ubuf, cnt);
+ return (ret == -EBUSY) ? 0 : ret;
+}
+
+static enum print_line_t process_print(struct trace_iterator *iter)
+{
+ struct trace_entry *entry = iter->ent;
+ struct trace_process *field;
+ struct trace_seq *s = &iter->seq;
+ unsigned long long t = ns2usecs(iter->ts);
+ unsigned long usec_rem = do_div(t, 1000000ULL);
+ unsigned secs = (unsigned long)t;
+ int ret = 1;
+
+ trace_assign_type(field, entry);
+
+ /* XXX: If print_lat_fmt() were not static, we wouldn't have
+ to duplicate this. */
+ trace_seq_printf(s, "%16s %5d %3d %9lu.%06ld ",
+ field->event.comm,
+ entry->pid, entry->cpu,
+ secs,
+ usec_rem);
+
+ switch (field->event.opcode) {
+ case _UTRACE_EVENT_CLONE:
+ ret = trace_seq_printf(s, "fork %d flags 0x%lx\n",
+ field->event.trace_clone.child,
+ field->event.trace_clone.flags);
+ break;
+ case _UTRACE_EVENT_EXEC:
+ ret = trace_seq_printf(s, "exec\n");
+ break;
+ case _UTRACE_EVENT_EXIT:
+ ret = trace_seq_printf(s, "exit %ld\n",
+ field->event.trace_exit.code);
+ break;
+ case _UTRACE_EVENT_SIGNAL:
+ ret = trace_seq_printf(s, "signal %d errno %d code 0x%x\n",
+ field->event.trace_signal.si_signo,
+ field->event.trace_signal.si_errno,
+ field->event.trace_signal.si_code);
+ break;
+ case _UTRACE_EVENT_SYSCALL_ENTRY:
+ ret = trace_seq_printf(s, "syscall %ld [0x%lx 0x%lx 0x%lx"
+ " 0x%lx 0x%lx 0x%lx]\n",
+ field->event.trace_syscall_entry.callno,
+ field->event.trace_syscall_entry.args[0],
+ field->event.trace_syscall_entry.args[1],
+ field->event.trace_syscall_entry.args[2],
+ field->event.trace_syscall_entry.args[3],
+ field->event.trace_syscall_entry.args[4],
+ field->event.trace_syscall_entry.args[5]);
+ break;
+ case _UTRACE_EVENT_SYSCALL_EXIT:
+ ret = trace_seq_printf(s, "syscall rc %ld error %ld\n",
+ field->event.trace_syscall_exit.rc,
+ field->event.trace_syscall_exit.error);
+ break;
+ default:
+ ret = trace_seq_printf(s, "process code %d?\n",
+ field->event.opcode);
+ break;
+ }
+ if (ret)
+ return TRACE_TYPE_HANDLED;
+ return TRACE_TYPE_HANDLED;
+}
+
+
+static enum print_line_t process_print_line(struct trace_iterator *iter)
+{
+ switch (iter->ent->type) {
+ case TRACE_PROCESS:
+ return process_print(iter);
+ default:
+ return TRACE_TYPE_HANDLED; /* ignore unknown entries */
+ }
+}
+
+static struct tracer process_tracer = {
+ .name = "process",
+ .init = process_trace_init,
+ .reset = process_trace_reset,
+ .start = process_trace_start,
+ .pipe_open = process_pipe_open,
+ .close = process_close,
+ .read = process_read,
+ .print_line = process_print_line,
+};
+
+
+
+/* utrace backend */
+
+/* Should tracing apply to given task? Compare against filter
+ values. */
+static int trace_test(struct task_struct *tsk)
+{
+ if (trace_taskcomm_filter[0]
+ && strncmp(trace_taskcomm_filter, tsk->comm, TASK_COMM_LEN))
+ return 0;
+
+ if (trace_taskuid_filter != (u32)-1
+ && trace_taskuid_filter != task_uid(tsk))
+ return 0;
+
+ return 1;
+}
+
+
+static const struct utrace_engine_ops process_trace_ops;
+
+static void process_trace_tryattach(struct task_struct *tsk)
+{
+ struct utrace_engine *engine;
+
+ pr_debug("in %s\n", __func__);
+ engine = utrace_attach_task(tsk,
+ UTRACE_ATTACH_CREATE |
+ UTRACE_ATTACH_EXCLUSIVE,
+ &process_trace_ops, NULL);
+ if (IS_ERR(engine) || (engine == NULL)) {
+ pr_warning("utrace_attach_task %d (rc %p)\n",
+ tsk->pid, engine);
+ } else {
+ int rc;
+
+ /* We always hook cost-free events. */
+ unsigned long events =
+ UTRACE_EVENT(CLONE) |
+ UTRACE_EVENT(EXEC) |
+ UTRACE_EVENT(EXIT);
+
+ /* Penalizing events are individually controlled, so that
+ utrace doesn't even take the monitored threads off their
+ fast paths, nor bother call our callbacks. */
+ if (trace_syscalls_p)
+ events |= UTRACE_EVENT_SYSCALL;
+ if (trace_signals_p)
+ events |= UTRACE_EVENT_SIGNAL_ALL;
+
+ rc = utrace_set_events(tsk, engine, events);
+ if (rc == -EINPROGRESS)
+ rc = utrace_barrier(tsk, engine);
+ if (rc)
+ pr_warning("utrace_set_events/barrier rc %d\n", rc);
+
+ utrace_engine_put(engine);
+ pr_debug("attached in %s to %s(%d)\n", __func__,
+ tsk->comm, tsk->pid);
+ }
+}
+
+
+u32 process_trace_report_clone(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *parent,
+ unsigned long clone_flags,
+ struct task_struct *child)
+{
+ if (trace_lifecycle_p && trace_test(parent)) {
+ struct process_trace_entry ent;
+ ent.opcode = _UTRACE_EVENT_CLONE;
+ ent.trace_clone.child = child->pid;
+ ent.trace_clone.flags = clone_flags;
+ process_trace(&ent);
+ }
+
+ process_trace_tryattach(child);
+
+ return UTRACE_RESUME;
+}
+
+
+u32 process_trace_report_syscall_entry(u32 action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ struct pt_regs *regs)
+{
+ if (trace_syscalls_p && trace_test(task)) {
+ struct process_trace_entry ent;
+ ent.opcode = _UTRACE_EVENT_SYSCALL_ENTRY;
+ ent.trace_syscall_entry.callno = syscall_get_nr(task, regs);
+ syscall_get_arguments(task, regs, 0, 6,
+ ent.trace_syscall_entry.args);
+ process_trace(&ent);
+ }
+
+ return UTRACE_RESUME;
+}
+
+
+u32 process_trace_report_syscall_exit(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ struct pt_regs *regs)
+{
+ if (trace_syscalls_p && trace_test(task)) {
+ struct process_trace_entry ent;
+ ent.opcode = _UTRACE_EVENT_SYSCALL_EXIT;
+ ent.trace_syscall_exit.rc =
+ syscall_get_return_value(task, regs);
+ ent.trace_syscall_exit.error = syscall_get_error(task, regs);
+ process_trace(&ent);
+ }
+
+ return UTRACE_RESUME;
+}
+
+
+u32 process_trace_report_exec(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ const struct linux_binfmt *fmt,
+ const struct linux_binprm *bprm,
+ struct pt_regs *regs)
+{
+ if (trace_lifecycle_p && trace_test(task)) {
+ struct process_trace_entry ent;
+ ent.opcode = _UTRACE_EVENT_EXEC;
+ process_trace(&ent);
+ }
+
+ /* We're already attached; no need for a new tryattach. */
+
+ return UTRACE_RESUME;
+}
+
+
+u32 process_trace_report_signal(u32 action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ struct pt_regs *regs,
+ siginfo_t *info,
+ const struct k_sigaction *orig_ka,
+ struct k_sigaction *return_ka)
+{
+ if (trace_signals_p && trace_test(task)) {
+ struct process_trace_entry ent;
+ ent.opcode = _UTRACE_EVENT_SIGNAL;
+ ent.trace_signal.si_signo = info->si_signo;
+ ent.trace_signal.si_errno = info->si_errno;
+ ent.trace_signal.si_code = info->si_code;
+ process_trace(&ent);
+ }
+
+ /* We're already attached, so no need for a new tryattach. */
+
+ return UTRACE_RESUME | utrace_signal_action(action);
+}
+
+
+u32 process_trace_report_exit(enum utrace_resume_action action,
+ struct utrace_engine *engine,
+ struct task_struct *task,
+ long orig_code, long *code)
+{
+ if (trace_lifecycle_p && trace_test(task)) {
+ struct process_trace_entry ent;
+ ent.opcode = _UTRACE_EVENT_EXIT;
+ ent.trace_exit.code = orig_code;
+ process_trace(&ent);
+ }
+
+ /* There is no need to explicitly attach or detach here. */
+
+ return UTRACE_RESUME;
+}
+
+
+void enable_process_trace()
+{
+ struct task_struct *grp, *tsk;
+
+ pr_debug("in %s\n", __func__);
+ rcu_read_lock();
+ do_each_thread(grp, tsk) {
+ /* Skip over kernel threads. */
+ if (tsk->flags & PF_KTHREAD)
+ continue;
+
+ if (process_follow_pid) {
+ if (tsk->tgid == process_follow_pid ||
+ tsk->parent->tgid == process_follow_pid)
+ process_trace_tryattach(tsk);
+ } else {
+ process_trace_tryattach(tsk);
+ }
+ } while_each_thread(grp, tsk);
+ rcu_read_unlock();
+}
+
+void disable_process_trace()
+{
+ struct utrace_engine *engine;
+ struct task_struct *grp, *tsk;
+ int rc;
+
+ pr_debug("in %s\n", __func__);
+ rcu_read_lock();
+ do_each_thread(grp, tsk) {
+ /* Find matching engine, if any. Returns -ENOENT for
+ unattached threads. */
+ engine = utrace_attach_task(tsk, UTRACE_ATTACH_MATCH_OPS,
+ &process_trace_ops, 0);
+ if (IS_ERR(engine)) {
+ if (PTR_ERR(engine) != -ENOENT)
+ pr_warning("utrace_attach_task %d (rc %ld)\n",
+ tsk->pid, -PTR_ERR(engine));
+ } else if (engine == NULL) {
+ pr_warning("utrace_attach_task %d (null engine)\n",
+ tsk->pid);
+ } else {
+ /* Found one of our own engines. Detach. */
+ rc = utrace_control(tsk, engine, UTRACE_DETACH);
+ switch (rc) {
+ case 0: /* success */
+ break;
+ case -ESRCH: /* REAP callback already begun */
+ case -EALREADY: /* DEATH callback already begun */
+ break;
+ default:
+ rc = -rc;
+ pr_warning("utrace_detach %d (rc %d)\n",
+ tsk->pid, rc);
+ break;
+ }
+ utrace_engine_put(engine);
+ pr_debug("detached in %s from %s(%d)\n", __func__,
+ tsk->comm, tsk->pid);
+ }
+ } while_each_thread(grp, tsk);
+ rcu_read_unlock();
+}
+
+
+static const struct utrace_engine_ops process_trace_ops = {
+ .report_clone = process_trace_report_clone,
+ .report_exec = process_trace_report_exec,
+ .report_exit = process_trace_report_exit,
+ .report_signal = process_trace_report_signal,
+ .report_syscall_entry = process_trace_report_syscall_entry,
+ .report_syscall_exit = process_trace_report_syscall_exit,
+};
+
+
+
+/* control interfaces */
+
+
+static ssize_t
+trace_taskcomm_filter_read(struct file *filp, char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ return simple_read_from_buffer(ubuf, cnt, ppos,
+ trace_taskcomm_filter, TASK_COMM_LEN);
+}
+
+
+static ssize_t
+trace_taskcomm_filter_write(struct file *filp, const char __user *ubuf,
+ size_t cnt, loff_t *fpos)
+{
+ char *end;
+
+ if (cnt > TASK_COMM_LEN)
+ cnt = TASK_COMM_LEN;
+
+ if (copy_from_user(trace_taskcomm_filter, ubuf, cnt))
+ return -EFAULT;
+
+ /* Cut from the first nil or newline. */
+ trace_taskcomm_filter[cnt] = '\0';
+ end = strchr(trace_taskcomm_filter, '\n');
+ if (end)
+ *end = '\0';
+
+ *fpos += cnt;
+ return cnt;
+}
+
+
+static const struct file_operations trace_taskcomm_filter_fops = {
+ .open = tracing_open_generic,
+ .read = trace_taskcomm_filter_read,
+ .write = trace_taskcomm_filter_write,
+};
+
+
+
+static char README_text[] =
+ "process event tracer mini-HOWTO\n"
+ "\n"
+ "1. Select process hierarchy to monitor. Other processes will be\n"
+ " completely unaffected. Leave at 0 for system-wide tracing.\n"
+ "# echo NNN > process_follow_pid\n"
+ "\n"
+ "2. Determine which process event traces are potentially desired.\n"
+ " syscall and signal tracing slow down monitored processes.\n"
+ "# echo 0 > process_trace_{syscalls,signals,lifecycle}\n"
+ "\n"
+ "3. Add any final uid- or taskcomm-based filtering. Non-matching\n"
+ " processes will skip trace messages, but will still be slowed.\n"
+ "# echo NNN > process_trace_uid_filter # -1: unrestricted \n"
+ "# echo ls > process_trace_taskcomm_filter # empty: unrestricted\n"
+ "\n"
+ "4. Start tracing.\n"
+ "# echo process > current_tracer\n"
+ "\n"
+ "5. Examine trace.\n"
+ "# cat trace\n"
+ "\n"
+ "6. Stop tracing.\n"
+ "# echo nop > current_tracer\n"
+ ;
+
+static struct debugfs_blob_wrapper README_blob = {
+ .data = README_text,
+ .size = sizeof(README_text),
+};
+
+
+static __init int init_process_trace(void)
+{
+ struct dentry *d_tracer;
+ struct dentry *entry;
+
+ d_tracer = tracing_init_dentry();
+
+ entry = debugfs_create_blob("process_trace_README", 0444, d_tracer,
+ &README_blob);
+ if (!entry)
+ pr_warning("Could not create debugfs "
+ "'process_trace_README' entry\n");
+
+ /* Control for scoping process following. */
+ entry = debugfs_create_u32("process_follow_pid", 0644, d_tracer,
+ &process_follow_pid);
+ if (!entry)
+ pr_warning("Could not create debugfs "
+ "'process_follow_pid' entry\n");
+
+ /* Process-level filters */
+ entry = debugfs_create_file("process_trace_taskcomm_filter", 0644,
+ d_tracer, NULL,
+ &trace_taskcomm_filter_fops);
+ /* XXX: it'd be nice to have a read/write debugfs_create_blob. */
+ if (!entry)
+ pr_warning("Could not create debugfs "
+ "'process_trace_taskcomm_filter' entry\n");
+
+ entry = debugfs_create_u32("process_trace_uid_filter", 0644, d_tracer,
+ &trace_taskuid_filter);
+ if (!entry)
+ pr_warning("Could not create debugfs "
+ "'process_trace_uid_filter' entry\n");
+
+ /* Event-level filters. */
+ entry = debugfs_create_u32("process_trace_lifecycle", 0644, d_tracer,
+ &trace_lifecycle_p);
+ if (!entry)
+ pr_warning("Could not create debugfs "
+ "'process_trace_lifecycle' entry\n");
+
+ entry = debugfs_create_u32("process_trace_syscalls", 0644, d_tracer,
+ &trace_syscalls_p);
+ if (!entry)
+ pr_warning("Could not create debugfs "
+ "'process_trace_syscalls' entry\n");
+
+ entry = debugfs_create_u32("process_trace_signals", 0644, d_tracer,
+ &trace_signals_p);
+ if (!entry)
+ pr_warning("Could not create debugfs "
+ "'process_trace_signals' entry\n");
+
+ return register_tracer(&process_tracer);
+}
+
+device_initcall(init_process_trace);
^ permalink raw reply related [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 1:42 ` [PATCH 3/3] utrace-based ftrace "process" engine, v2 Roland McGrath
@ 2009-03-21 7:43 ` Ingo Molnar
2009-03-21 8:39 ` Andrew Morton
0 siblings, 1 reply; 53+ messages in thread
From: Ingo Molnar @ 2009-03-21 7:43 UTC (permalink / raw)
To: Roland McGrath, Steven Rostedt
Cc: Andrew Morton, utrace-devel, Frank Eigler, linux-kernel
* Roland McGrath <roland@redhat.com> wrote:
> From: Frank Ch. Eigler <fche@redhat.com>
>
> This is v2 of the prototype utrace-ftrace interface. This code is
> based on Roland McGrath's utrace API, which provides programmatic
> hooks to the in-tree tracehook layer. This new patch interfaces
> many of those events to ftrace, as configured by a small number of
> debugfs controls. Here's the
> /debugfs/tracing/process_trace_README:
Please submit changes/enhancements to kernel/trace/* to the tracing
tree maintainers (Steve and me) for review, testing and integration.
Please also post patches against the latest tracing tree:
http://people.redhat.com/mingo/tip.git/README
As this patch does not apply:
Applying patch patches/utrace-based-ftrace-process-engine-v2.patch
patching file include/linux/processtrace.h
patching file kernel/trace/Kconfig
Hunk #1 succeeded at 186 with fuzz 2 (offset 36 lines).
patching file kernel/trace/Makefile
Hunk #1 FAILED at 33.
1 out of 1 hunk FAILED -- rejects in file kernel/trace/Makefile
patching file kernel/trace/trace.h
Hunk #1 succeeded at 7 with fuzz 1.
Hunk #2 FAILED at 31.
Hunk #3 succeeded at 215 with fuzz 2 (offset 43 lines).
Hunk #4 FAILED at 330.
2 out of 4 hunks FAILED -- rejects in file kernel/trace/trace.h
patching file kernel/trace/trace_process.c
Patch patches/utrace-based-ftrace-process-engine-v2.patch does not apply (enforce with -f)
Thanks,
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 7:43 ` Ingo Molnar
@ 2009-03-21 8:39 ` Andrew Morton
2009-03-21 9:12 ` Ingo Molnar
0 siblings, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2009-03-21 8:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: Roland McGrath, Steven Rostedt, utrace-devel, Frank Eigler,
linux-kernel
On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Roland McGrath <roland@redhat.com> wrote:
>
> > From: Frank Ch. Eigler <fche@redhat.com>
> >
> > This is v2 of the prototype utrace-ftrace interface. This code is
> > based on Roland McGrath's utrace API, which provides programmatic
> > hooks to the in-tree tracehook layer. This new patch interfaces
> > many of those events to ftrace, as configured by a small number of
> > debugfs controls. Here's the
> > /debugfs/tracing/process_trace_README:
>
> Please submit changes/enhancements to kernel/trace/* to the tracing
> tree maintainers (Steve and me) for review, testing and integration.
>
> Please also post patches against the latest tracing tree:
>
> http://people.redhat.com/mingo/tip.git/README
uhm, this patch depends on the (large) utrace patch, which is not kernel/trace
material.
> As this patch does not apply:
>
> Applying patch patches/utrace-based-ftrace-process-engine-v2.patch
> patching file include/linux/processtrace.h
> patching file kernel/trace/Kconfig
> Hunk #1 succeeded at 186 with fuzz 2 (offset 36 lines).
> patching file kernel/trace/Makefile
> Hunk #1 FAILED at 33.
> 1 out of 1 hunk FAILED -- rejects in file kernel/trace/Makefile
> patching file kernel/trace/trace.h
> Hunk #1 succeeded at 7 with fuzz 1.
> Hunk #2 FAILED at 31.
> Hunk #3 succeeded at 215 with fuzz 2 (offset 43 lines).
> Hunk #4 FAILED at 330.
> 2 out of 4 hunks FAILED -- rejects in file kernel/trace/trace.h
> patching file kernel/trace/trace_process.c
> Patch patches/utrace-based-ftrace-process-engine-v2.patch does not apply (enforce with -f)
The rejects are trivial.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 1:41 ` [PATCH 2/3] utrace core Roland McGrath
@ 2009-03-21 8:49 ` Andrew Morton
2009-03-21 14:08 ` Renzo Davoli
` (2 more replies)
0 siblings, 3 replies; 53+ messages in thread
From: Andrew Morton @ 2009-03-21 8:49 UTC (permalink / raw)
To: Roland McGrath; +Cc: utrace-devel, linux-kernel
On Fri, 20 Mar 2009 18:41:40 -0700 (PDT) Roland McGrath <roland@redhat.com> wrote:
> This adds the utrace facility, a new modular interface in the kernel for
> implementing user thread tracing and debugging. This fits on top of the
> tracehook_* layer, so the new code is well-isolated.
>
> The new interface is in <linux/utrace.h> and the DocBook utrace book
> describes it. It allows for multiple separate tracing engines to work in
> parallel without interfering with each other. Higher-level tracing
> facilities can be implemented as loadable kernel modules using this layer.
>
> The new facility is made optional under CONFIG_UTRACE.
> When this is not enabled, no new code is added.
> It can only be enabled on machines that have all the
> prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK.
>
> In this initial version, utrace and ptrace do not play together at all.
> If ptrace is attached to a thread, the attach calls in the utrace kernel
> API return -EBUSY. If utrace is attached to a thread, the PTRACE_ATTACH
> or PTRACE_TRACEME request will return EBUSY to userland. The old ptrace
> code is otherwise unchanged and nothing using ptrace should be affected
> by this patch as long as utrace is not used at the same time. In the
> future we can clean up the ptrace implementation and rework it to use
> the utrace API.
I'd be interested in seeing a bit of discussion regarding the overall value
of utrace - it has been quite a while since it floated past.
I assume that redoing ptrace to be a client of utrace _will_ happen, and
that this is merely a cleanup exercise with no new user-visible features?
The "prototype utrace-ftrace interface" seems to be more a cool toy rather
than a serious new kernel feature (yes?)
If so, what are the new killer utrace clients which would justify all these
changes?
Also, is it still the case that RH are shipping utrace? If so, for what
reasons and what benefits are users seeing from it?
And I recall that there were real problems wiring up the Feb 2007 version
of utrace to the ARM architecture. Have those issues been resolved? Are
any problems expected for any architectures?
Thanks.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 8:39 ` Andrew Morton
@ 2009-03-21 9:12 ` Ingo Molnar
2009-03-21 11:19 ` Andrew Morton
2009-03-23 4:49 ` Roland McGrath
0 siblings, 2 replies; 53+ messages in thread
From: Ingo Molnar @ 2009-03-21 9:12 UTC (permalink / raw)
To: Andrew Morton
Cc: Roland McGrath, Steven Rostedt, utrace-devel, Frank Eigler,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
* Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> >
> > * Roland McGrath <roland@redhat.com> wrote:
> >
> > > From: Frank Ch. Eigler <fche@redhat.com>
> > >
> > > This is v2 of the prototype utrace-ftrace interface. This code is
> > > based on Roland McGrath's utrace API, which provides programmatic
> > > hooks to the in-tree tracehook layer. This new patch interfaces
> > > many of those events to ftrace, as configured by a small number of
> > > debugfs controls. Here's the
> > > /debugfs/tracing/process_trace_README:
> >
> > Please submit changes/enhancements to kernel/trace/* to the tracing
> > tree maintainers (Steve and me) for review, testing and integration.
> >
> > Please also post patches against the latest tracing tree:
> >
> > http://people.redhat.com/mingo/tip.git/README
>
> uhm, this patch depends on the (large) utrace patch, which is not
> kernel/trace material.
The thing is, utrace crashes in Fedora have dominated kerneloops.org
for many months, so i'm not sure what to make of the idea of posting
a 4000+ lines of core kernel code patchset on the last day of the
development cycle, a posting that has carefully avoided the Cc:-ing
of affected maintainers ;-)
Utrace is very much tracing material - without the ftrace plugin the
whole utrace machinery is just something that provides a _ton_ of
hooks to something entirely external: SystemTap mainly.
kernel/utrace.c should probably be introduced as
kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending
work in the tracing tree and cooperation would be nice and desired.
The ftrace/utrace plugin is the only real connection utrace has to
the mainline kernel, so proper review by the tracing folks and
cooperation with the tracing folks is very much needed for the whole
thing.
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 9:12 ` Ingo Molnar
@ 2009-03-21 11:19 ` Andrew Morton
2009-03-21 11:51 ` Frank Ch. Eigler
2009-03-23 4:49 ` Roland McGrath
1 sibling, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2009-03-21 11:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Roland McGrath, Steven Rostedt, utrace-devel, Frank Eigler,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
On Sat, 21 Mar 2009 10:12:35 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > >
> > > * Roland McGrath <roland@redhat.com> wrote:
> > >
> > > > From: Frank Ch. Eigler <fche@redhat.com>
> > > >
> > > > This is v2 of the prototype utrace-ftrace interface. This code is
> > > > based on Roland McGrath's utrace API, which provides programmatic
> > > > hooks to the in-tree tracehook layer. This new patch interfaces
> > > > many of those events to ftrace, as configured by a small number of
> > > > debugfs controls. Here's the
> > > > /debugfs/tracing/process_trace_README:
> > >
> > > Please submit changes/enhancements to kernel/trace/* to the tracing
> > > tree maintainers (Steve and me) for review, testing and integration.
> > >
> > > Please also post patches against the latest tracing tree:
> > >
> > > http://people.redhat.com/mingo/tip.git/README
> >
> > uhm, this patch depends on the (large) utrace patch, which is not
> > kernel/trace material.
>
> The thing is, utrace crashes in Fedora have dominated kerneloops.org
> for many months, so i'm not sure what to make of the idea of posting
> a 4000+ lines of core kernel code patchset on the last day of the
> development cycle, a posting that has carefully avoided the Cc:-ing
> of affected maintainers ;-)
>
> Utrace is very much tracing material - without the ftrace plugin the
> whole utrace machinery is just something that provides a _ton_ of
> hooks to something entirely external: SystemTap mainly.
Roland's changelogs don't mention systemtap at all afacit.
That was, umm, major information lossage.
> kernel/utrace.c should probably be introduced as
> kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending
> work in the tracing tree and cooperation would be nice and desired.
>
> The ftrace/utrace plugin is the only real connection utrace has to
> the mainline kernel, so proper review by the tracing folks and
> cooperation with the tracing folks is very much needed for the whole
> thing.
Actually it seems that the whole utrace-ftrace thing is a big distraction and
could/should just be omitted. This is a systemtap feature and should be viewed as
such.
This is all a bit weird.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 11:19 ` Andrew Morton
@ 2009-03-21 11:51 ` Frank Ch. Eigler
2009-03-21 12:04 ` Andrew Morton
0 siblings, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-21 11:51 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
Hi -
On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> [...]
> > Utrace is very much tracing material - without the ftrace plugin the
> > whole utrace machinery is just something that provides a _ton_ of
> > hooks to something entirely external: SystemTap mainly.
>
> Roland's changelogs don't mention systemtap at all afacit.
> That was, umm, major information lossage.
There have been many mixed messages from LKML on the topic - sometimes
mentioning systemtap is forbidden, other times necessary. Sorry about
that.
There are several non-systemtap clients in existence or under
development. You've may have heard of the ptrace cleanup, a
multi-client ptrace replacement, an on-the-fly core dumper, the ftrace
widget, user-space probes. All of these should have somewhat
compelling non-systemtap uses, if that's an important criterion.
> Actually it seems that the whole utrace-ftrace thing is a big
> distraction and could/should just be omitted. This is a systemtap
> feature and should be viewed as such. [...]
utrace is a better way to perform user thread management than what is
there now, and the utrace-ftrace widget shows how to *hook* thread
events such as syscalls in a lighter weight / more managed way than
the first one proposed. (That's one reason we've been participating
in the ftrace discussions.) Of course it can be made to use the fine
syscall pretty-printing code recently added.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 11:51 ` Frank Ch. Eigler
@ 2009-03-21 12:04 ` Andrew Morton
2009-03-21 12:57 ` Frank Ch. Eigler
` (3 more replies)
0 siblings, 4 replies; 53+ messages in thread
From: Andrew Morton @ 2009-03-21 12:04 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Ingo Molnar, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche@redhat.com> wrote:
> Hi -
>
> On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> > [...]
> > > Utrace is very much tracing material - without the ftrace plugin the
> > > whole utrace machinery is just something that provides a _ton_ of
> > > hooks to something entirely external: SystemTap mainly.
> >
> > Roland's changelogs don't mention systemtap at all afacit.
> > That was, umm, major information lossage.
>
> There have been many mixed messages from LKML on the topic - sometimes
> mentioning systemtap is forbidden, other times necessary. Sorry about
> that.
heh. We all love systemtap and want it to get better.
> There are several non-systemtap clients in existence or under
> development. You've may have heard of the ptrace cleanup, a
> multi-client ptrace replacement, an on-the-fly core dumper, the ftrace
> widget, user-space probes. All of these should have somewhat
> compelling non-systemtap uses, if that's an important criterion.
Well I dunno. You guys are closer to this than I am, but I'd have thought
that systemtap is the main game here, and most/all of the above is just
fluff.
IOW, "this helps systemtap" is sufficient reason for merging a kernel
change. For sufficiently large values of "help", and sufficiently small
values of "eww", of course.
I have strong memories of being traumatised by reading the uprobes code.
What's the story on all of that nowadays?
>
> > Actually it seems that the whole utrace-ftrace thing is a big
> > distraction and could/should just be omitted. This is a systemtap
> > feature and should be viewed as such. [...]
>
> utrace is a better way to perform user thread management than what is
> there now, and the utrace-ftrace widget shows how to *hook* thread
> events such as syscalls in a lighter weight / more managed way than
> the first one proposed. (That's one reason we've been participating
> in the ftrace discussions.) Of course it can be made to use the fine
> syscall pretty-printing code recently added.
eh. Boring. Let's fix systemtap?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 12:04 ` Andrew Morton
@ 2009-03-21 12:57 ` Frank Ch. Eigler
2009-03-21 15:45 ` Ingo Molnar
` (2 subsequent siblings)
3 siblings, 0 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-21 12:57 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
Hi -
On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> [...]
> > There have been many mixed messages from LKML on the topic - sometimes
> > mentioning systemtap is forbidden, other times necessary. Sorry about
> > that.
>
> heh. We all love systemtap and want it to get better.
Great!
> [...]
> I have strong memories of being traumatised by reading the uprobes
> code. What's the story on all of that nowadays?
uprobes, being a layer upon utrace that provides a kprobes-like
breakpointing API for user threads, is being refactored into several
parts. I don't know about the aesthetics of it all, but I believe the
general future plan is this:
One piece would perform machine code analysis (to classify
instructions for ideal/safe placement of breakpoints or for code
patching), and another thin layer that uses this and utrace to manage
user-space breakpoints. (Systemtap would interface at this point.)
Then a user-space syscallish interface could come along to expose this
to a super-ptrace client (to speed up gdb; perhaps to allow multiple
debuggers). Plus one might as well add an ftrace-engine for it
(directly analogous to the recent kprobe-based one that ftrace people
found "cool".)
> > > Actually it seems that the whole utrace-ftrace thing is a big
> > > distraction and could/should just be omitted. This is a systemtap
> > > feature and should be viewed as such. [...]
> >
> > utrace is a better way to perform user thread management than what is
> > there now, and the utrace-ftrace widget shows how to *hook* thread
> > events such as syscalls in a lighter weight / more managed way than
> > the first one proposed. (That's one reason we've been participating
> > in the ftrace discussions.) Of course it can be made to use the fine
> > syscall pretty-printing code recently added.
>
> eh. Boring. Let's fix systemtap?
There are several constituencies here, some of which find the above
exciting. That's OK and we'd like to help them too.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 8:49 ` Andrew Morton
@ 2009-03-21 14:08 ` Renzo Davoli
2009-03-21 14:34 ` Ingo Molnar
2009-03-23 4:35 ` Roland McGrath
2009-03-23 10:57 ` Will Newton
2 siblings, 1 reply; 53+ messages in thread
From: Renzo Davoli @ 2009-03-21 14:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: Roland McGrath, utrace-devel, linux-kernel
Tracing does not mean only debug. Some tracing facilities can be used for virtualization.
For example User-Mode Linux is based on ptrace.
I have a prototype of kernel module for virtualization (kmview) based on utrace.
Using kmview (module+VMM) it is possible for a user (not root) to mount a filesystem just for
a process (or a hierarchy of processes), or it is possible for some processes to
use different networking stacks or virtual devices. It is something like user-mode containers.
kmview provides the same features of umview, based on ptrace, in a (very) faster way.
(umview is in Debian lenny,squeeze,sid if you want to test it)
*Utrace is really what I wanted* to support kmview (apart from
some minor issues about the support of nested virtualizations).
Other virtualizations now based on ptrace could move part of their implementation
at kernel level by utrace and several speedups become possible.
For example kmview is a partial virtual machine monitor: some system calls are forwarded
to the kernel, some others virtualized.
When a user mounts a filesystem, all the system calls which use pathnames inside the mountpoint
subtree get virtualized while the others are forwarded to the kernel.
With utrace the kmview kernel module handles many system calls at kernel level.
I mean, if an "open" system call was sent to the kernel because the path is outside
the virtualized part of the file system, all the system calls on the same file descriptors
can be forwarded to the kernel without any request to the VMM at user level.
This is just one example of speedup, several others are possible.
Other virtualizations like user-mode linux or fakeroot-ng could use utrace to
speedup their virtualization, too.
As far as I have seen, systemtap is a wonderful tool for debugging, expecially for
kernel debugging but it has not been designed for virtualization.
Ptrace provide a standard set of features and all the implementations of VMM must be
in userland. Utrace provides the flexibility to split a VMM and move part of it to a
kernel module.
Utrace provides a unified interface to kernel modules for tracing/virtualization.
kmview can be implemented as a client of utrace or by spreading code around the kernel and
like kmview other virtualizations based on ptrace could need to move some of their
logic to the kernel to speedup their execution.
These VMMs will use utrace based modules instead of kernel patches.
renzo
On Sat, Mar 21, 2009 at 01:49:09AM -0700, Andrew Morton wrote:
> I'd be interested in seeing a bit of discussion regarding the overall value
> of utrace - it has been quite a while since it floated past.
>
> I assume that redoing ptrace to be a client of utrace _will_ happen, and
> that this is merely a cleanup exercise with no new user-visible features?
>
> The "prototype utrace-ftrace interface" seems to be more a cool toy rather
> than a serious new kernel feature (yes?)
>
> If so, what are the new killer utrace clients which would justify all these
> changes?
>
> Also, is it still the case that RH are shipping utrace? If so, for what
> reasons and what benefits are users seeing from it?
>
> And I recall that there were real problems wiring up the Feb 2007 version
> of utrace to the ARM architecture. Have those issues been resolved? Are
> any problems expected for any architectures?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 14:08 ` Renzo Davoli
@ 2009-03-21 14:34 ` Ingo Molnar
2009-03-21 16:37 ` Renzo Davoli
0 siblings, 1 reply; 53+ messages in thread
From: Ingo Molnar @ 2009-03-21 14:34 UTC (permalink / raw)
To: Renzo Davoli; +Cc: Andrew Morton, Roland McGrath, utrace-devel, linux-kernel
* Renzo Davoli <renzo@cs.unibo.it> wrote:
> Tracing does not mean only debug. Some tracing facilities can be
> used for virtualization. For example User-Mode Linux is based on
> ptrace.
>
> I have a prototype of kernel module for virtualization (kmview)
> based on utrace. [...]
Hm, i cannot find the source code. Can it be downloaded from
somewhere?
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 12:04 ` Andrew Morton
2009-03-21 12:57 ` Frank Ch. Eigler
@ 2009-03-21 15:45 ` Ingo Molnar
2009-03-21 20:35 ` Diego Calleja
` (2 more replies)
2009-03-23 5:09 ` Roland McGrath
2009-03-24 5:29 ` Ananth N Mavinakayanahalli
3 siblings, 3 replies; 53+ messages in thread
From: Ingo Molnar @ 2009-03-21 15:45 UTC (permalink / raw)
To: Andrew Morton
Cc: Frank Ch. Eigler, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
* Andrew Morton <akpm@linux-foundation.org> wrote:
> [...] Let's fix systemtap?
Yes, it needs to be fixed.
The main issue i see is that no kernel developer i work with on a
daily basis uses SystemTap - and i work with a lot of people. Yes, i
could perhaps name two or three people from lkml using it, but its
average penetration amongst kernel folks is essentially zero.
Was any critical analysis done why that penetration is so absymally
low for a tool with such a promise and with years of availability,
and what are the measures planned to address those problems?
To me personally there are two big direct usability issues with
SystemTap:
1) It relies on DEBUG_INFO for any reasonable level of utility.
Yes, it will limp along otherwise as well, but most of the
actual novel capabilities depend on debuginfo. Which is an
acceptable constraint for enterprise usage where kernels are
switched every few months and having a debuginfo package is not
a big issue. Not acceptable for upstream kernel development. It
also puts way too trust into the compiler generating 1GB+ of
debuginfo correctly. I want to be able to rely on tools all the
time and thus i want tools to have some really simple and
predictable foundations.
2) It's not upstream and folks using it seem to insist on not
having it upstream ;-) This 'distance' to upstream seems to have
grown during the past few years - instead of shrinking. As a
result it simply does not matter and there's no know-how and no
visibility of it upstream.
If these fundamental problems are addressed then i'd even argue for
the totality of SystemTap to be aimed upstreamed (including the
scripting language, etc.), because for something this fundamental
there's just no good reason not to have a turn-key solution there.
Plus then there should be a (steadily growing) library of utility
scripts in the kernel proper as well.
Anything less does not make much sense IMO. Having a separate tool
will reduce efficiency, increases the latency of fixes and
enhancements and creates ABI-like expectations - which are all
counter-productive to good instrumentation.
These are the aspects of SystemTap that i have to say were never
done right, and these are the aspects of SystemTap that need to
change most. Putting utrace upstream now will just make it more
convenient to have SystemTap as a separate entity - without any of
the benefits. Do we want to do that? Maybe, but we could do better i
think.
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 14:34 ` Ingo Molnar
@ 2009-03-21 16:37 ` Renzo Davoli
2009-03-21 16:44 ` Ingo Molnar
0 siblings, 1 reply; 53+ messages in thread
From: Renzo Davoli @ 2009-03-21 16:37 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, Roland McGrath, utrace-devel, linux-kernel
On Sat, Mar 21, 2009 at 03:34:57PM +0100, Ingo Molnar wrote:
>
> * Renzo Davoli <renzo@cs.unibo.it> wrote:
>
> > Tracing does not mean only debug. Some tracing facilities can be
> > used for virtualization. For example User-Mode Linux is based on
> > ptrace.
> >
> > I have a prototype of kernel module for virtualization (kmview)
> > based on utrace. [...]
>
> Hm, i cannot find the source code. Can it be downloaded from
> somewhere?
Sure! kmview is not included in our Debian packages yet as it relies on
(still) non mainstream features (utrace), but the code is available on
our view-os svn repository.
Check out:
svn co https://view-os.svn.sourceforge.net/svnroot/view-os view-os
More specifically to browse the code/specifications:
The kmview device protocol is here:
http://wiki.virtualsquare.org/index.php/KMview_module_interface_specifications
The kernel module itself is here:
http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/kmview-kernel-module/
The VMM userland application share most of the code with
umview, the source code for both is here:
http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/xmview-os/xmview/
kmview kernel module (current version) needs the following patches:
utrace
http://www.mail-archive.com/utrace-devel@redhat.com/msg00654.html
http://www.mail-archive.com/utrace-devel@redhat.com/msg00655.html
I am trying to keep everything up to date, but the whole stuff is
evolving in a quite fast way.
Everything has been released under GPLv2.
renzo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 16:37 ` Renzo Davoli
@ 2009-03-21 16:44 ` Ingo Molnar
2009-03-23 4:34 ` Roland McGrath
0 siblings, 1 reply; 53+ messages in thread
From: Ingo Molnar @ 2009-03-21 16:44 UTC (permalink / raw)
To: Renzo Davoli; +Cc: Andrew Morton, Roland McGrath, utrace-devel, linux-kernel
* Renzo Davoli <renzo@cs.unibo.it> wrote:
> On Sat, Mar 21, 2009 at 03:34:57PM +0100, Ingo Molnar wrote:
> >
> > * Renzo Davoli <renzo@cs.unibo.it> wrote:
> >
> > > Tracing does not mean only debug. Some tracing facilities can be
> > > used for virtualization. For example User-Mode Linux is based on
> > > ptrace.
> > >
> > > I have a prototype of kernel module for virtualization (kmview)
> > > based on utrace. [...]
> >
> > Hm, i cannot find the source code. Can it be downloaded from
> > somewhere?
>
> Sure! kmview is not included in our Debian packages yet as it
> relies on (still) non mainstream features (utrace), but the code
> is available on our view-os svn repository.
>
> Check out:
> svn co https://view-os.svn.sourceforge.net/svnroot/view-os view-os
>
> More specifically to browse the code/specifications:
> The kmview device protocol is here:
> http://wiki.virtualsquare.org/index.php/KMview_module_interface_specifications
> The kernel module itself is here:
> http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/kmview-kernel-module/
Looks really interesting.
That's btw. what i see as the biggest value of utrace: it's a
comprehesive, all-encompassing framework all around process state
events and process state manipulation.
Utrace came from Frysk (generic debugger), but the fact that you
were able to build a completely unanticipated usecase and
virtualization module on top of it is a very good sign of a robust
and complete design. I'm impressed.
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 15:45 ` Ingo Molnar
@ 2009-03-21 20:35 ` Diego Calleja
2009-03-22 12:17 ` Ingo Molnar
2009-03-21 21:34 ` Andrew Morton
2009-03-21 21:48 ` Frank Ch. Eigler
2 siblings, 1 reply; 53+ messages in thread
From: Diego Calleja @ 2009-03-21 20:35 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Frank Ch. Eigler, Roland McGrath, Steven Rostedt,
utrace-devel, linux-kernel, Linus Torvalds, Peter Zijlstra,
Thomas Gleixner
On Sábado 21 Marzo 2009 16:45:01 Ingo Molnar escribió:
> The main issue i see is that no kernel developer i work with on a
> daily basis uses SystemTap - and i work with a lot of people. Yes, i
> could perhaps name two or three people from lkml using it, but its
> average penetration amongst kernel folks is essentially zero.
What about userspace developers? People always talks of systemtap as
a kernel thing, but my (humble) impression is that kernel hackers don't
seem to need it that much (maybe for the same reasons they didn't a
kernel debugger ;), but userspace developers do. There're many
userspace projects that offer optional compile options to enable dtrace
probes (some people like apple even ship executables of python, perl
and ruby with probes by default). There're several firefox hackers that
switched to dtrace-capable systems just because the dtrace-javascript
probes enabled them to debug javashit code in ways they weren't able
in linux or windows.
In my humble opinion a better development environment for linux
userspace programmers is way more important than whether kernel
hackers like systemtap or not. So maybe the discussion should be less
about "does it help kernel hackers?" and more about "does it help
userspace hackers?". My 2¢...
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 15:45 ` Ingo Molnar
2009-03-21 20:35 ` Diego Calleja
@ 2009-03-21 21:34 ` Andrew Morton
2009-03-21 21:51 ` Frank Ch. Eigler
2009-03-21 21:48 ` Frank Ch. Eigler
2 siblings, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2009-03-21 21:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: Frank Ch. Eigler, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
On Sat, 21 Mar 2009 16:45:01 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> [...]
>
useful, thanks.
> Putting utrace upstream now will just make it more
> convenient to have SystemTap as a separate entity - without any of
> the benefits. Do we want to do that? Maybe, but we could do better i
> think.
It would not be good to merge a large kernel feature which kernel
developers and testers cannot test, and regression test.
If testing utrace against its main application requires installation of a
complete enterprise distro from a distro which the particular developer
might not prefer to use then that's quite a problem.
So it is desirable for this reason (and, I suspect, for other reasons) that
systemtap (or a part thereof) be dragged out in some standalone form which
is usable by random mortals.
IOW: I agree.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 15:45 ` Ingo Molnar
2009-03-21 20:35 ` Diego Calleja
2009-03-21 21:34 ` Andrew Morton
@ 2009-03-21 21:48 ` Frank Ch. Eigler
2009-03-22 12:08 ` Ingo Molnar
2 siblings, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-21 21:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
Hi -
On Sat, Mar 21, 2009 at 04:45:01PM +0100, Ingo Molnar wrote:
> [...]
> To me personally there are two big direct usability issues with
> SystemTap:
>
> 1) It relies on DEBUG_INFO for any reasonable level of utility.
> Yes, it will limp along otherwise as well, but most of the
> actual novel capabilities depend on debuginfo. Which is an
> acceptable constraint for enterprise usage where kernels are
> switched every few months and having a debuginfo package is not
> a big issue. Not acceptable for upstream kernel development.
In my own limited kernel-building experience, I find the debuginfo
data conveniently and instantly available after every "make". Can you
elaborate how is it harder for you to incidentally make it than for
someone to download it?
> It also puts way too trust into the compiler generating 1GB+ of
> debuginfo correctly. I want to be able to rely on tools all the
> time and thus i want tools to have some really simple and
> predictable foundations.
Well, the data has to come from *somewhere*. We know several
shortcomings (and have staff working on gcc debuginfo improvements),
but there is little alternative. If not from the compiler, where are
you going to get detailed type/structure layouts? Stack slot to
variable mappings? Statement-level PC addresses? Unwind data?
> 2) It's not upstream and folks using it seem to insist on not
> having it upstream ;-) This 'distance' to upstream seems to have
> grown during the past few years - instead of shrinking. [...]
Considering our upstream-bound assistance with foundation technologies
like markers, tracepoints, kprobes, utrace, and several other bits,
this does not seem entirely fair.
> If these fundamental problems are addressed then i'd even argue for
> the totality of SystemTap to be aimed upstreamed (including the
> scripting language, etc.), [...]
If consensus on this were plausible, we could seriously discuss it.
But I don't buy the package-deal that utrace must not attempt merging
on its own merits, just because it makes systemtap (as it is today)
useful to more people.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 21:34 ` Andrew Morton
@ 2009-03-21 21:51 ` Frank Ch. Eigler
2009-03-21 22:02 ` Linus Torvalds
0 siblings, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-21 21:51 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
Hi -
On Sat, Mar 21, 2009 at 02:34:13PM -0700, Andrew Morton wrote:
> [...]
> It would not be good to merge a large kernel feature which kernel
> developers and testers cannot test, and regression test.
It does not. Other kernel self-sufficient utrace clients are on their
way, and of course one was just (re)posted.
> If testing utrace against its main application requires installation
> of a complete enterprise distro from a distro [...]
This has *never* been a requirement.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 21:51 ` Frank Ch. Eigler
@ 2009-03-21 22:02 ` Linus Torvalds
2009-03-21 22:20 ` Frank Ch. Eigler
2009-03-22 12:37 ` Ingo Molnar
0 siblings, 2 replies; 53+ messages in thread
From: Linus Torvalds @ 2009-03-21 22:02 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Andrew Morton, Ingo Molnar, Roland McGrath, Steven Rostedt,
utrace-devel, linux-kernel, Peter Zijlstra, Thomas Gleixner
On Sat, 21 Mar 2009, Frank Ch. Eigler wrote:
>
> > If testing utrace against its main application requires installation
> > of a complete enterprise distro from a distro [...]
>
> This has *never* been a requirement.
You guys are getting off a tangent.
Let's go back to the post that started this all.
> The thing is, utrace crashes in Fedora have dominated kerneloops.org
> for many months, so i'm not sure what to make of the idea of posting
> a 4000+ lines of core kernel code patchset on the last day of the
> development cycle, a posting that has carefully avoided the Cc:-ing
> of affected maintainers ;-)
.. and dammit, I agree 100%. If utrace really shows up in _any_ way on
kerneloops.org, then I think THE ENTIRE DISCUSSION in this thread is moot.
I'm not going to take known-bad crap. It's that simple. Don't bother
posting it, don't bother discussing it, don't bother making excuses for
it.
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 22:02 ` Linus Torvalds
@ 2009-03-21 22:20 ` Frank Ch. Eigler
2009-03-21 22:37 ` Alexey Dobriyan
2009-03-22 12:37 ` Ingo Molnar
1 sibling, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-21 22:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Ingo Molnar, Roland McGrath, Steven Rostedt,
utrace-devel, linux-kernel, Peter Zijlstra, Thomas Gleixner
Hi -
On Sat, Mar 21, 2009 at 03:02:59PM -0700, Linus Torvalds wrote:
> [...]
> > The thing is, utrace crashes in Fedora have dominated kerneloops.org
> > for many months [...]
>
> .. and dammit, I agree 100%. If utrace really shows up in _any_ way on
> kerneloops.org, then I think THE ENTIRE DISCUSSION in this thread is moot.
There was a short span of time during last fall, when Roland was on
vacation. That bug (in 2.6.26.3) was fixed during the kernel summit.
So this is a six-month obsolete grievance.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 22:20 ` Frank Ch. Eigler
@ 2009-03-21 22:37 ` Alexey Dobriyan
2009-03-21 23:38 ` Frank Ch. Eigler
0 siblings, 1 reply; 53+ messages in thread
From: Alexey Dobriyan @ 2009-03-21 22:37 UTC (permalink / raw)
To: Frank Ch. Eigler, Roland McGrath
Cc: Linus Torvalds, Andrew Morton, Ingo Molnar, Steven Rostedt,
utrace-devel, linux-kernel, Peter Zijlstra, Thomas Gleixner
On Sat, Mar 21, 2009 at 06:20:30PM -0400, Frank Ch. Eigler wrote:
> On Sat, Mar 21, 2009 at 03:02:59PM -0700, Linus Torvalds wrote:
> > [...]
> > > The thing is, utrace crashes in Fedora have dominated kerneloops.org
> > > for many months [...]
> >
> > .. and dammit, I agree 100%. If utrace really shows up in _any_ way on
> > kerneloops.org, then I think THE ENTIRE DISCUSSION in this thread is moot.
>
> There was a short span of time during last fall, when Roland was on
> vacation. That bug (in 2.6.26.3) was fixed during the kernel summit.
> So this is a six-month obsolete grievance.
struct task_struct::utrace became embedded struct. This is good and
should remove quite a few of utrace bugs. Better late than never.
However, "rewrite-ptrace-via-utrace" patch was omitted, so almost noone
can easily see by how much situation improved.
I see this patch was dropped in Fedora.
Will ptrace(2) will be rewritten through utrace?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 22:37 ` Alexey Dobriyan
@ 2009-03-21 23:38 ` Frank Ch. Eigler
2009-03-22 10:25 ` Ingo Molnar
2009-03-23 5:20 ` Roland McGrath
0 siblings, 2 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-21 23:38 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Roland McGrath, Linus Torvalds, Andrew Morton, Ingo Molnar,
Steven Rostedt, utrace-devel, linux-kernel, Peter Zijlstra,
Thomas Gleixner
Hi -
On Sun, Mar 22, 2009 at 01:37:59AM +0300, Alexey Dobriyan wrote:
> [...]
> struct task_struct::utrace became embedded struct. This is good and
> should remove quite a few of utrace bugs. Better late than never.
Yeah.
> However, "rewrite-ptrace-via-utrace" patch was omitted, so almost
> noone can easily see by how much situation improved. [...] Will
> ptrace(2) will be rewritten through utrace?
Yes, I believe that is Roland's intent. I believe it was separated
from the current suite of patches for staging purposes, to merge the
most solid code up first. The code is available from the utrace git
tree in the utrace-ptrace branch.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 23:38 ` Frank Ch. Eigler
@ 2009-03-22 10:25 ` Ingo Molnar
2009-03-23 5:33 ` Roland McGrath
2009-03-23 5:20 ` Roland McGrath
1 sibling, 1 reply; 53+ messages in thread
From: Ingo Molnar @ 2009-03-22 10:25 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Alexey Dobriyan, Roland McGrath, Linus Torvalds, Andrew Morton,
Steven Rostedt, utrace-devel, linux-kernel, Peter Zijlstra,
Thomas Gleixner
* Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> On Sun, Mar 22, 2009 at 01:37:59AM +0300, Alexey Dobriyan wrote:
> > [...]
> > struct task_struct::utrace became embedded struct. This is good and
> > should remove quite a few of utrace bugs. Better late than never.
>
> Yeah.
>
> > However, "rewrite-ptrace-via-utrace" patch was omitted, so
> > almost noone can easily see by how much situation improved.
> > [...] Will ptrace(2) will be rewritten through utrace?
>
> Yes, I believe that is Roland's intent. I believe it was
> separated from the current suite of patches for staging purposes,
> to merge the most solid code up first. The code is available from
> the utrace git tree in the utrace-ptrace branch.
i think they should be submitted together.
Here's the histogram of utrace bugs on kerneloops.org:
2.6.27.5 1 x
2.6.27.15 1 x
2.6.27.12 2 x
2.6.27-rc4 2 x
2.6.26.6 1 x
2.6.26.5 43 x
2.6.26.3 1102 x
2.6.26.2 2 x
2.6.26.1 3 x
2.6.26 1 x
2.6.25 3 x
That peak in 2.6.26.3 is what i referred to. The latest F10 kernel
rpm is kernel-2.6.27.12-170.2.5.fc10, and it does include the
utrace-ptrace engine as well:
# grep UTRACE /boot/config-2.6.27.19-170.2.35.fc10.i686
CONFIG_UTRACE=y
CONFIG_UTRACE_PTRACE=y
So the bug i referred to was fixed and the bug count has gone down -
but still we have the utrace core submission here without any
(tested) mainline kernel usage of the core code.
My suggestion would be to:
- submit the ptrace-on-utrace engine as well (with Oleg's signoff?)
- perhaps also submit with a well-tested ftrace plugin that tries
to utilize _all_ aspects of utrace and ftrace (and hence gives
good and continuous burn-in testing via the ftrace bootup
self-tests, etc.)
ideally we want both, because:
- tracing corner-case bugs tend to be found much faster than ptrace
corner case bugs - partly because tracing is much more invasive
when activated system-wide.
- ptrace-over-utrace on the other hand utilizes utrace more deeply
than passive tracing ever can. (for example UML does full,
active virtualization via ptrace - this depth of functional
utrace usage is not possible via a tracing plugin.)
And i think the ptrace-via-utrace engine is actually fully ready,
just perhaps it was not submitted out of caution to keep the
logistics simple.
So i do think we've still got a shot at merging it, in this merge
window.
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 21:48 ` Frank Ch. Eigler
@ 2009-03-22 12:08 ` Ingo Molnar
2009-03-22 12:53 ` Ingo Molnar
2009-03-23 20:25 ` Frank Ch. Eigler
0 siblings, 2 replies; 53+ messages in thread
From: Ingo Molnar @ 2009-03-22 12:08 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Andrew Morton, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
* Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> On Sat, Mar 21, 2009 at 04:45:01PM +0100, Ingo Molnar wrote:
> > [...]
> > To me personally there are two big direct usability issues with
> > SystemTap:
> >
> > 1) It relies on DEBUG_INFO for any reasonable level of utility.
> > Yes, it will limp along otherwise as well, but most of the
> > actual novel capabilities depend on debuginfo. Which is an
> > acceptable constraint for enterprise usage where kernels are
> > switched every few months and having a debuginfo package is not
> > a big issue. Not acceptable for upstream kernel development.
>
> In my own limited kernel-building experience, I find the debuginfo
> data conveniently and instantly available after every "make". Can
> you elaborate how is it harder for you to incidentally make it
> than for someone to download it?
Four reasons:
1)
I have CONFIG_DEBUG_INFO turned off in 99.9% of my kernel builds,
because it slows down the kernel build times significantly:
without: 4343.31 user 416.39 system 6:09.97 elapsed 1286%CPU
with: 4871.07 user 501.90 system 7:43.22 elapsed 1159 %CPU
( x86 allyesconfig. On an obscenely overpowered Nehalem box
with 12 GB of RAM. )
2)
When the kernel build becomes IO-bound, for example when i build
over a distcc cluster (which is how i generally build my kernels) -
or when others with less RAM build a debuginfo kernel, the ratio
becomes even worse:
without: 870.36 user 292.79 system 3:32.10 elapsed 548% CPU
with: 929.65 user 384.55 system 8:28.70 elapsed 258% CPU
3)
Another metric. Here's an x86 defconfig (i.e. fairly regular config
- not allyesconfig) build's size:
with: 1645 MB
without: 211 MB
Try to build 1.6 GB of dirty data on ext3 and run into an fsync() in
your editor ... you'll sit there twiddling thumbs for a minute or
more.
4)
Or yet another metric - Linux distro package overhead. Try
installing a debuginfo package:
# yum install kernel-debuginfo
==========================================
Package Arch Version
==========================================
Installing:
kernel-debuginfo x86_64 2.6.29-0.258.rc8.git2.fc11
rawhide-debuginfo 294 M
Installing for dependencies:
kernel-debuginfo-common x86_64 2.6.29-0.258.rc8.git2.fc11
rawhide-debuginfo 35 M
Total download size: 329 M
That size of a _compressed_ debuginfo kernel package is obscene. We
can fit 4 years of full Linux kernel Git history into that size -
60,000+ commits, full metadata and full 20 million lines of code
flux included!
Uncompressed it blows up to gigabytes of on-disk data.
And this download has to be repeated for _every_ minor kernel
upgrade.
So when i come into a situation where i could use some debugging
help ... i'd have to rebuild the kernel with DEBUG_INFO=y and i'll
always notice when i have a debuginfo kernel because it's
inconvenient.
The solution?)
Dunno - but i definitely think we should think bigger:
The fundamental disconnect i believe seems to come from the fact
that most user-space projects are relatively small, so debuginfo
bloat is a secondary issue there.
But for a project with the size of the kernel, even for moderate
builds (not allyesconfig), it's a _much_ bigger deal. This has been
known for a long time and the situation has become worse over the
last two years, not better. (last time i checked the debuginfo
package overhead it was below 150 MB)
A few random ideas:
Instead of trying to cache 2+GB of debuginfo for a 50 MB kernel
source repo (+50 MB of genuine .o output) - just to be able to debug
one or two source files [which is the typical scope of a debugging
session], why not build debuginfo on the fly, when a debugging
session requires it? Rarely do we need debuginfo for more than a
fraction of the whole kernel.
( Yes, it needs a few smarts like knowing the SHA1 of the source
code module that a particular kernel portion got built with, to
make sure the debuginfo is fresh and relevant - but nothing major. )
I mean, lets _use_ the fact that we have source code available, more
intelligently. It takes zero time to build detailed debuginfo for a
portion of a tree.
If 'download debuginfo' can be replaced with: 'have a recent Git
repository of the distro kernel source', we'll have a _much_ more
efficient use of resources all around.
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 20:35 ` Diego Calleja
@ 2009-03-22 12:17 ` Ingo Molnar
0 siblings, 0 replies; 53+ messages in thread
From: Ingo Molnar @ 2009-03-22 12:17 UTC (permalink / raw)
To: Diego Calleja
Cc: Andrew Morton, Frank Ch. Eigler, Roland McGrath, Steven Rostedt,
utrace-devel, linux-kernel, Linus Torvalds, Peter Zijlstra,
Thomas Gleixner
* Diego Calleja <diegocg@gmail.com> wrote:
> On Sábado 21 Marzo 2009 16:45:01 Ingo Molnar escribió:
>
> > The main issue i see is that no kernel developer i work with on a
> > daily basis uses SystemTap - and i work with a lot of people. Yes, i
> > could perhaps name two or three people from lkml using it, but its
> > average penetration amongst kernel folks is essentially zero.
>
> What about userspace developers? People always talks of systemtap
> as a kernel thing, but my (humble) impression is that kernel
> hackers don't seem to need it that much (maybe for the same
> reasons they didn't a kernel debugger ;), but userspace developers
> do. There're many userspace projects that offer optional compile
> options to enable dtrace probes (some people like apple even ship
> executables of python, perl and ruby with probes by default).
> There're several firefox hackers that switched to dtrace-capable
> systems just because the dtrace-javascript probes enabled them to
> debug javashit code in ways they weren't able in linux or windows.
>
> In my humble opinion a better development environment for linux
> userspace programmers is way more important than whether kernel
> hackers like systemtap or not. So maybe the discussion should be
> less about "does it help kernel hackers?" and more about "does it
> help userspace hackers?". My 2¢...
Well, i consider kernel development to be just another form of
software development, so i dont subscribe to the view that it is
intrinsically different. (Yes, the kernel has many unique aspects -
but most software projects have unique aspects.)
In terms of development methodology and tools, in fact i claim that
the kernel workflow and style of development can be applied to most
user-space software projects with great success.
So ... if a new development tool is apparently not (yet?) suited to
a very large and sanely developed software project like the Linux
kernel, i dont take that as an encouraging sign.
Also, there's practical aspects: the kernel is what we know best so
if we can make it work well for the kernel, hopes are that other
large projects can use it too. If we _only_ make the tool good for
non-kernel purposes, who else will fix it for the kernel? The
icentive to fix it for the kernel will be significantly lower.
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 22:02 ` Linus Torvalds
2009-03-21 22:20 ` Frank Ch. Eigler
@ 2009-03-22 12:37 ` Ingo Molnar
2009-03-23 13:48 ` Alexey Dobriyan
1 sibling, 1 reply; 53+ messages in thread
From: Ingo Molnar @ 2009-03-22 12:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Frank Ch. Eigler, Andrew Morton, Roland McGrath, Steven Rostedt,
utrace-devel, linux-kernel, Peter Zijlstra, Thomas Gleixner,
Oleg Nesterov, Alexey Dobriyan
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, 21 Mar 2009, Frank Ch. Eigler wrote:
> >
> > > If testing utrace against its main application requires installation
> > > of a complete enterprise distro from a distro [...]
> >
> > This has *never* been a requirement.
>
> You guys are getting off a tangent.
>
> Let's go back to the post that started this all.
>
> > The thing is, utrace crashes in Fedora have dominated kerneloops.org
> > for many months, so i'm not sure what to make of the idea of posting
> > a 4000+ lines of core kernel code patchset on the last day of the
> > development cycle, a posting that has carefully avoided the Cc:-ing
> > of affected maintainers ;-)
>
> .. and dammit, I agree 100%. If utrace really shows up in _any_
> way on kerneloops.org, then I think THE ENTIRE DISCUSSION in this
> thread is moot.
>
> I'm not going to take known-bad crap. It's that simple. Don't
> bother posting it, don't bother discussing it, don't bother making
> excuses for it.
The kerneloops stats on utrace crashes are way down currently,
after that peak last fall. So i didnt want to suggest that it's
known-broken now - i only wanted to point out that it's a
known-risky area and that the submission of it should involve
the affected maintainers/developers.
Regarding current stability, Roland, Frank, is the utrace patch in
latest (today's) Fedora rawhide:
-rw-r--r-- 1 root root 176555 2009-01-08 05:42 linux-2.6-utrace.patch
a bug fixed equivalent of the utrace bits that crashed in the
2.6.26.3 kernel? In that case it is certainly known-good.
Or is it a slimmed-down version?
The ptrace bits and signoffs from Oleg and Alexey would certainly
help (me) in trusting it. (I've Cc:-ed Oleg and Alexey)
The ftrace bits could certainly be staged to go in via the tracing
tree (in .31 or so) after the utrace-core+ptrace bits went upstream.
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-22 12:08 ` Ingo Molnar
@ 2009-03-22 12:53 ` Ingo Molnar
2009-03-23 20:25 ` Frank Ch. Eigler
1 sibling, 0 replies; 53+ messages in thread
From: Ingo Molnar @ 2009-03-22 12:53 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Andrew Morton, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
* Ingo Molnar <mingo@elte.hu> wrote:
> Total download size: 329 M
>
> That size of a _compressed_ debuginfo kernel package is obscene.
> We can fit 4 years of full Linux kernel Git history into that size
> - 60,000+ commits, full metadata and full 20 million lines of code
> flux included!
>
> Uncompressed it blows up to gigabytes of on-disk data.
>
> And this download has to be repeated for _every_ minor kernel
> upgrade.
Have to correct my memories about how many commits the kernel repo
has: 132,019 commits. That massive history fits into 298 MB. (!)
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 16:44 ` Ingo Molnar
@ 2009-03-23 4:34 ` Roland McGrath
0 siblings, 0 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-23 4:34 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Renzo Davoli, Andrew Morton, utrace-devel, linux-kernel
> That's btw. what i see as the biggest value of utrace: it's a
> comprehesive, all-encompassing framework all around process state
> events and process state manipulation.
Me too!
And while we're on the btw's, I want to let everyone know that Ingo is the
one who came up with the name "utrace". I had only completely dismal ideas
for names, and nothing but the philosophy, "For the love of God, anything
but [a-z]trace!" So that's one tiny piece of the whole mess that you can't
blame on me. (Yes, I do believe I would be killed if we changed it again now.)
;-) ;-) ;-)
> Utrace came from Frysk (generic debugger), but the fact that you
> were able to build a completely unanticipated usecase and
> virtualization module on top of it is a very good sign of a robust
> and complete design. I'm impressed.
Um, thanks, I guess. The antecedents of your statement are not really
accurate, but I'll take the consequent as a compliment! :-)
In fact, utrace came from my experience of maintaining the old ptrace code.
Nor was this particular use "completely unanticipated".
I was not aware of Renzo or his work before he got in touch about making
use of utrace. But my imagined list of vaporware always included
"specialized engines for UML or other syscall-interception type things".
(e.g. seccomp is trivial with no need for per-arch asm work.) I swear,
a third of the people who ever came to me complaining about ptrace being
so hard to work with were doing things that to me are all "syscall
interception and/or tracking", whether for some security-minded purpose
or something more virtualization-like. Surely for many of those cases,
it was really the wrong way to solve the problem they were tackling.
Seems it's just the next stop after someone talks you out of LD_PRELOAD.
But who am I to say? It was quite clear that people really wanted
easier ways to experiment with doing this sort of thing.
That said, I certainly have always hoped for completely unanticipated
uses. (I will readily admit to succumbing to "Build it and they will
come" mentality. I'm sure flames about my deep character flaws, moral
turpitude, and dubious lineage will follow. The history of my career
will show that I was not striving for the appearance of cogent planning.)
I hatched the essential design of utrace when I'd recently spent a whole
lot of time fixing the innards of ptrace and a whole lot of time helping
userland implementors of debuggers and the like figure out how to work
with ptrace (and hearing their complaints about it). At the same time,
the group I'm in (still) was contemplating both the implementation
issues of a generic debugger, how to make it tractable to work up to far
smarter debuggers, and also the design of what became systemtap.
It was clear to me that this whole space of problems and potential
features would be an open-ended area where different approaches would
need to be hashed out, and that there would not be one "ptrace killer"
feature that would be the right fit for all uses. It has long been
clear that the threshold of effort was far too high for people to
experiment and innovate in this area. Hence the plan to make a new
platform that lowered that threshold at least closer to "pretty easy"
from "intractable", staying about as simple as what both brings that
threshold down enough and lets unrelated developments in these things
coexist well on the system.
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 8:49 ` Andrew Morton
2009-03-21 14:08 ` Renzo Davoli
@ 2009-03-23 4:35 ` Roland McGrath
2009-03-23 10:57 ` Will Newton
2 siblings, 0 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-23 4:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: utrace-devel, linux-kernel
> I'd be interested in seeing a bit of discussion regarding the overall value
> of utrace - it has been quite a while since it floated past.
Me too!
> I assume that redoing ptrace to be a client of utrace _will_ happen, and
> that this is merely a cleanup exercise with no new user-visible features?
Yes. It's my expectation that Oleg and I will do that clean-up in
several small stages, in the not-too-distant future. I think more of
that work has to do with making the ptrace data structures clean and
sane than with utrace details.
> The "prototype utrace-ftrace interface" seems to be more a cool toy rather
> than a serious new kernel feature (yes?)
I don't personally have any experience with either Frank's utrace-ftrace
widget or with using any ftrace-based things to debug user programs.
I would guess it is more of a demonstration than a tool people will be
using in the long run.
> If so, what are the new killer utrace clients which would justify all these
> changes?
I hope I can leave those examples to the people who will write them.
utrace will be a failure if it only serves to underlie the things I want
to implement or can think up. My intent is to open up this area of new
feature generation to the people who are killer hackers, but have been
daunted or turned off by the prospect of becoming killer ptrace innards
hackers. (Only Oleg seems to have taken to that opportunity, or perhaps
he expected to wind up doing it as little as I did.)
> Also, is it still the case that RH are shipping utrace? If so, for what
> reasons and what benefits are users seeing from it?
Fedora Rawhide has this current code, yes. The people trying to
develop new features using utrace certainly like having it there.
(There really truly are people who like to build novel kernel modules
without compiling their own kernels from scratch.) I won't try to
speak for them or their users.
> And I recall that there were real problems wiring up the Feb 2007 version
> of utrace to the ARM architecture. Have those issues been resolved? Are
> any problems expected for any architectures?
That was a misimpression. There were never real problems for ARM,
only misunderstandings. I'm sure the way I tried to stage the changes
at that time contributed to those misunderstandings arising as they
did. Since then, all the arch requirements have been distilled into
the HAVE_ARCH_TRACEHOOK set that is already merged for several
architectures. It is in the hands of each arch maintainer to update
their code to meet the HAVE_ARCH_TRACEHOOK requirements (I'm glad to
give advice when asked), and there is no porting work that is actually
specific to utrace itself. (You just can't turn it on without
HAVE_ARCH_TRACEHOOK.) Of course it is never all that unlikely that
some bits of the generic code will get some new tweaks brought to
light by making it work with a particular arch. To my knowledge, the
strangest arch for cleaning up any of this stuff has always been ia64,
and sparc second; those arch maintainers have already done the
HAVE_ARCH_TRACEHOOK work.
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 9:12 ` Ingo Molnar
2009-03-21 11:19 ` Andrew Morton
@ 2009-03-23 4:49 ` Roland McGrath
2009-03-23 6:34 ` Ingo Molnar
1 sibling, 1 reply; 53+ messages in thread
From: Roland McGrath @ 2009-03-23 4:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Steven Rostedt, utrace-devel, Frank Eigler,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
> kernel/utrace.c should probably be introduced as
> kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending
> work in the tracing tree and cooperation would be nice and desired.
Of course I would like to cooperate with everyone. And of course it does
not really matter much where a source file lives. But IMHO utrace really
does not fit in with the kernel/trace/ code much at all. Sure, its hooks
can be used by tracer implementations that use CONFIG_TRACING stuff. But
it is a general API about user thread state. It belongs in kernel/trace/
"naturally" far less than, say, kprobes. utrace will in future be used to
implement userland features (ptrace et al) that are just aspects of the
basics of what an operating system does: mediate userland for userland.
Those uses will have nothing to do with "kernel tracing".
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 12:04 ` Andrew Morton
2009-03-21 12:57 ` Frank Ch. Eigler
2009-03-21 15:45 ` Ingo Molnar
@ 2009-03-23 5:09 ` Roland McGrath
2009-03-24 5:29 ` Ananth N Mavinakayanahalli
3 siblings, 0 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-23 5:09 UTC (permalink / raw)
To: Andrew Morton
Cc: Frank Ch. Eigler, Ingo Molnar, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
> Well I dunno. You guys are closer to this than I am, but I'd have thought
> that systemtap is the main game here, and most/all of the above is just
> fluff.
That is certainly not true for me. It is true that I hear plenty from
systemtap developers, users, and boosters wanting utrace to be merged.
But all that "fluff" you dismiss out of hand is what I would really like
to see become reality. Pretty much the only people who ever tell me
they would hack on those things are the ones who say, "I'm looking
forward to utrace getting merged in so I can try to write something."
> eh. Boring. [...]
Since it's boring to you, it must be so boring to everyone that they
have no interest in a platform they can use to do exciting things with.
Great. Silly me trying to enable collaboration to produce things less
boring than I'm capable of myself. Clearly there is no need for any
such thing. Sorry I'm so out of touch, but I just thought it was cool.
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 23:38 ` Frank Ch. Eigler
2009-03-22 10:25 ` Ingo Molnar
@ 2009-03-23 5:20 ` Roland McGrath
1 sibling, 0 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-23 5:20 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Alexey Dobriyan, Linus Torvalds, Andrew Morton, Ingo Molnar,
Steven Rostedt, utrace-devel, linux-kernel, Peter Zijlstra,
Thomas Gleixner
> Yes, I believe that is Roland's intent. I believe it was separated
> from the current suite of patches for staging purposes, to merge the
> most solid code up first. The code is available from the utrace git
> tree in the utrace-ptrace branch.
More than just "staging". The utrace-ptrace code there today is really not
very nice to look at, and it's not ready for prime time. As has been
mentioned, it is a "pure clean-up exercise". As such, it's not the top
priority. It also didn't seem to me like much of an argument for merging
utrace: "Look, more code and now it still does the same thing!"
Instead, I figured we should merge utrace in a way that lets everybody beat
on it for new features and hash out details, without immediate risk of
regressions in ptrace (which are severely annoying to everyone when they
happen). The proper clean-ups for ptrace can proceed in parallel with work
using utrace for things that are actually new and interesting, and at least
the first half of that clean-up work is orthogonal to utrace.
This seems like the normal way that new optional CONFIG_FOOBAR features
(marked EXPERIMENTAL, even) are handled. We don't jump over ourselves to
make existing crucial code paths subject to a new subsystem that is getting
its first rounds of shake-out.
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-22 10:25 ` Ingo Molnar
@ 2009-03-23 5:33 ` Roland McGrath
0 siblings, 0 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-23 5:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Frank Ch. Eigler, Alexey Dobriyan, Linus Torvalds, Andrew Morton,
Steven Rostedt, utrace-devel, linux-kernel, Peter Zijlstra,
Thomas Gleixner
> And i think the ptrace-via-utrace engine is actually fully ready,
> just perhaps it was not submitted out of caution to keep the
> logistics simple.
That's not so. There is a clumsy prototype version. Much of the work to
do it properly is really just plain ptrace clean-up and not specifically
about using utrace. Oleg and I are ready to work on it as soon as our time
is not monopolized by trying to get the core utrace code to be accepted.
This ptrace work really buys nothing with immediate pay-off at all. It's a
real shame if its lack keeps people from actually looking at utrace itself.
(This has been a long conversation so far with zero discussion of the code.)
A collaboration with focus on what new things can be built, rather than on
reasons not to let the foundations be poured, would be a lovely thing.
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-23 4:49 ` Roland McGrath
@ 2009-03-23 6:34 ` Ingo Molnar
0 siblings, 0 replies; 53+ messages in thread
From: Ingo Molnar @ 2009-03-23 6:34 UTC (permalink / raw)
To: Roland McGrath
Cc: Andrew Morton, Steven Rostedt, utrace-devel, Frank Eigler,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
* Roland McGrath <roland@redhat.com> wrote:
> > kernel/utrace.c should probably be introduced as
> > kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending
> > work in the tracing tree and cooperation would be nice and desired.
>
> Of course I would like to cooperate with everyone. And of course
> it does not really matter much where a source file lives. But
> IMHO utrace really does not fit in with the kernel/trace/ code
> much at all. Sure, its hooks can be used by tracer
> implementations that use CONFIG_TRACING stuff. But it is a
> general API about user thread state. It belongs in kernel/trace/
> "naturally" far less than, say, kprobes. utrace will in future be
> used to implement userland features (ptrace et al) that are just
> aspects of the basics of what an operating system does: mediate
> userland for userland. Those uses will have nothing to do with
> "kernel tracing".
But it is fitting if you think of kernel/trace/ as
kernel/instrumentation/.
The virtualization-alike uses for utrace are in essence using system
call instrumentation callbacks to inject extra functionality into
the system. That's possible not because it's primarily geared at
doing that, but because the instrumentation callbacks are generic
and complete enough. It's still correct to think of it as an
instrumentation tool and to maintain it as such. That also makes it
clear that none of these APIs are to be regarded permanent ABIs.
Anyway ... placement is no big deal, and kernel/utrace.c is
certainly a good way of avoiding the tracing tree ;-)
Ingo
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 2/3] utrace core
2009-03-21 8:49 ` Andrew Morton
2009-03-21 14:08 ` Renzo Davoli
2009-03-23 4:35 ` Roland McGrath
@ 2009-03-23 10:57 ` Will Newton
2 siblings, 0 replies; 53+ messages in thread
From: Will Newton @ 2009-03-23 10:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: Roland McGrath, utrace-devel, linux-kernel
On Sat, Mar 21, 2009 at 8:49 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 20 Mar 2009 18:41:40 -0700 (PDT) Roland McGrath <roland@redhat.com> wrote:
>
>> This adds the utrace facility, a new modular interface in the kernel for
>> implementing user thread tracing and debugging. This fits on top of the
>> tracehook_* layer, so the new code is well-isolated.
>>
>> The new interface is in <linux/utrace.h> and the DocBook utrace book
>> describes it. It allows for multiple separate tracing engines to work in
>> parallel without interfering with each other. Higher-level tracing
>> facilities can be implemented as loadable kernel modules using this layer.
>>
>> The new facility is made optional under CONFIG_UTRACE.
>> When this is not enabled, no new code is added.
>> It can only be enabled on machines that have all the
>> prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK.
>>
>> In this initial version, utrace and ptrace do not play together at all.
>> If ptrace is attached to a thread, the attach calls in the utrace kernel
>> API return -EBUSY. If utrace is attached to a thread, the PTRACE_ATTACH
>> or PTRACE_TRACEME request will return EBUSY to userland. The old ptrace
>> code is otherwise unchanged and nothing using ptrace should be affected
>> by this patch as long as utrace is not used at the same time. In the
>> future we can clean up the ptrace implementation and rework it to use
>> the utrace API.
>
> I'd be interested in seeing a bit of discussion regarding the overall value
> of utrace - it has been quite a while since it floated past.
>
> I assume that redoing ptrace to be a client of utrace _will_ happen, and
> that this is merely a cleanup exercise with no new user-visible features?
>
> The "prototype utrace-ftrace interface" seems to be more a cool toy rather
> than a serious new kernel feature (yes?)
>
> If so, what are the new killer utrace clients which would justify all these
> changes?
It looks like utrace could provide a nice way to do low latency
tracing of userspace processes via a hardware interface (e.g. JTAG or
custom trace hardware). The only way to do that at present is to
scatter bits of instrumentation throughout the kernel.
I would like to see utrace merged so I can work on that type of feature.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-22 12:37 ` Ingo Molnar
@ 2009-03-23 13:48 ` Alexey Dobriyan
2009-03-23 15:14 ` Oleg Nesterov
0 siblings, 1 reply; 53+ messages in thread
From: Alexey Dobriyan @ 2009-03-23 13:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frank Ch. Eigler, Andrew Morton, Roland McGrath,
Steven Rostedt, utrace-devel, linux-kernel, Peter Zijlstra,
Thomas Gleixner, Oleg Nesterov
On Sun, Mar 22, 2009 at 01:37:49PM +0100, Ingo Molnar wrote:
> The ptrace bits and signoffs from Oleg and Alexey would certainly
> help (me) in trusting it. (I've Cc:-ed Oleg and Alexey)
The further utrace stays away from mainline, the better.
That's from my experience with this code.
But let's see how ptrace(2) rewrite will look like because this is
the biggest thing that matters. All those cool virtual machines,
fancy tracers and what not aren't even comparable.
Right now with ptrace(2) rewrite the following is easily triggerable:
WARNING: at kernel/ptrace.c:515 ptrace_report_signal+0x2c1/0x2d0()
Pid: 4814, comm: exe Not tainted 2.6.29-rc8-utrace #1
Call Trace:
[<c0126df1>] warn_slowpath+0x81/0xa0
[<c014c359>] ? validate_chain+0xe9/0x1150
[<c014d606>] ? __lock_acquire+0x246/0xa50
[<c0232959>] ? __delay+0x9/0x10
[<c014b8eb>] ? mark_held_locks+0x6b/0x80
[<c03d3dd2>] ? _spin_unlock_irq+0x22/0x50
[<c012fdd1>] ptrace_report_signal+0x2c1/0x2d0
[<c012fb10>] ? ptrace_report_signal+0x0/0x2d0
[<c0154a79>] utrace_get_signal+0x1c9/0x660
[<c0135478>] get_signal_to_deliver+0x288/0x330
[<c01029e9>] do_notify_resume+0xb9/0x890
[<c017edd2>] ? cache_free_debugcheck+0x232/0x2f0
[<c014957b>] ? trace_hardirqs_off+0xb/0x10
[<c03d3d79>] ? _spin_unlock_irqrestore+0x39/0x70
[<c01015a0>] ? sys_execve+0x40/0x60
[<c017f139>] ? kmem_cache_free+0x89/0xc0
[<c014baad>] ? trace_hardirqs_on_caller+0xfd/0x190
[<c014bb4b>] ? trace_hardirqs_on+0xb/0x10
[<c010340a>] work_notifysig+0x13/0x19
It looks like WARN_ON is just bogus, but who knows.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-23 13:48 ` Alexey Dobriyan
@ 2009-03-23 15:14 ` Oleg Nesterov
2009-03-23 21:44 ` Theodore Tso
0 siblings, 1 reply; 53+ messages in thread
From: Oleg Nesterov @ 2009-03-23 15:14 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Ingo Molnar, Linus Torvalds, Frank Ch. Eigler, Andrew Morton,
Roland McGrath, Steven Rostedt, utrace-devel, linux-kernel,
Peter Zijlstra, Thomas Gleixner
On 03/23, Alexey Dobriyan wrote:
>
> Right now with ptrace(2) rewrite the following is easily triggerable:
>
> WARNING: at kernel/ptrace.c:515 ptrace_report_signal+0x2c1/0x2d0()
Yes, ptrace-over-utrace needs more work. But your message looks as if
utrace core is buggy, imho this is a bit unfair ;)
As Roland said, ptrace-over-utrace is not ready yet. If you mean that
utrace core should not be merged alone - this is another story.
But personally I understand why Roland sends utrace core before changing
ptrace.
Oleg.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-22 12:08 ` Ingo Molnar
2009-03-22 12:53 ` Ingo Molnar
@ 2009-03-23 20:25 ` Frank Ch. Eigler
2009-03-23 20:39 ` Linus Torvalds
1 sibling, 1 reply; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-23 20:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner
Hi -
On Sun, Mar 22, 2009 at 01:08:11PM +0100, Ingo Molnar wrote:
> [...]
> > In my own limited kernel-building experience, I find the debuginfo
> > data conveniently and instantly available after every "make". Can
> > you elaborate how is it harder for you to incidentally make it
> > than for someone to download it?
>
> Four reasons:
>
> 1)
>
> I have CONFIG_DEBUG_INFO turned off in 99.9% of my kernel builds,
> because it slows down the kernel build times significantly: [...]
OK, 15% longer time.
> 2)
>
> When the kernel build becomes IO-bound [...]
> without: 870.36 user 292.79 system 3:32.10 elapsed 548% CPU
> with: 929.65 user 384.55 system 8:28.70 elapsed 258% CPU
OK, lots of network traffic.
> 3) [...]
> Try to build 1.6 GB of dirty data on ext3 and run into an fsync() in
> your editor ... you'll sit there twiddling thumbs for a minute or
> more.
Now don't go blaming us for ext3 & fsync & not having a low enough
/proc/sys/vm/dirty_background_ratio.
> 4)
> Or yet another metric - Linux distro package overhead. Try
> installing a debuginfo package: [...]
Same as 3).
> And this download has to be repeated for _every_ minor kernel
> upgrade.
Actually, no. If you just want to run the newly built kernel
somewhere else on your network, you can run a systemtap compile server
on your build machine, and let the systemtap network client do ~RPCs
to get at the data.
> The solution?)
>
> Dunno - but i definitely think we should think bigger:
>
> The fundamental disconnect i believe seems to come from the fact
> that most user-space projects are relatively small, so debuginfo
> bloat is a secondary issue there.
(Well, the fedora debuginfo archive shows a couple of packages of
similar or greater heft than the kernel - openoffice.org, qt3, ...)
> A few random ideas:
>
> [...] why not build debuginfo on the fly, when a debugging
> session requires it? Rarely do we need debuginfo for more than a
> fraction of the whole kernel. [...]
> I mean, lets _use_ the fact that we have source code available, more
> intelligently. It takes zero time to build detailed debuginfo for a
> portion of a tree. [...]
Something like that might be made to work.
Note that this backs away from earlier claims that we can make do
without debuginfo, or that the compiler can't be trusted to build the
stuff. We all agree it'd be nice if made it better and made a little
less.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-23 20:25 ` Frank Ch. Eigler
@ 2009-03-23 20:39 ` Linus Torvalds
0 siblings, 0 replies; 53+ messages in thread
From: Linus Torvalds @ 2009-03-23 20:39 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: Ingo Molnar, Andrew Morton, Roland McGrath, Steven Rostedt,
utrace-devel, linux-kernel, Peter Zijlstra, Thomas Gleixner
On Mon, 23 Mar 2009, Frank Ch. Eigler wrote:
> > I have CONFIG_DEBUG_INFO turned off in 99.9% of my kernel builds,
> > because it slows down the kernel build times significantly: [...]
>
> OK, 15% longer time.
It's way more than that if you don't have tons of memory and excessive
amounts of CPU power.
> > 2)
> >
> > When the kernel build becomes IO-bound [...]
> > without: 870.36 user 292.79 system 3:32.10 elapsed 548% CPU
> > with: 929.65 user 384.55 system 8:28.70 elapsed 258% CPU
>
> OK, lots of network traffic.
This is the _normal_ situation for a debug info build. If it's not
network traffic (distcc), it's just disk IO. Have you tried it on a
laptop? Ingo is not the only one that turns off DEBUG_INFO in disgust.
It's totally useless for any sane kernel developer - the costs are
excessive.
Adn that's totally ignoring the disk usage of multiple debug info kernels.
> Note that this backs away from earlier claims that we can make do
> without debuginfo, or that the compiler can't be trusted to build the
> stuff. We all agree it'd be nice if made it better and made a little
> less.
Gaah. I'd wish you all agreed that DEBUG_INFO is just TOTALLY UNREALISTIC.
Linus
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-23 15:14 ` Oleg Nesterov
@ 2009-03-23 21:44 ` Theodore Tso
2009-03-30 22:18 ` Andrew Morton
0 siblings, 1 reply; 53+ messages in thread
From: Theodore Tso @ 2009-03-23 21:44 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Alexey Dobriyan, Ingo Molnar, Linus Torvalds, Frank Ch. Eigler,
Andrew Morton, Roland McGrath, Steven Rostedt, utrace-devel,
linux-kernel, Peter Zijlstra, Thomas Gleixner
On Mon, Mar 23, 2009 at 04:14:00PM +0100, Oleg Nesterov wrote:
>
> Yes, ptrace-over-utrace needs more work. But your message looks as if
> utrace core is buggy, imho this is a bit unfair ;)
>
> As Roland said, ptrace-over-utrace is not ready yet. If you mean that
> utrace core should not be merged alone - this is another story.
>
> But personally I understand why Roland sends utrace core before changing
> ptrace.
Yes, but if it's going to be merged this during 2.6.x cycle, we need
to have a user for the kernel interface along with the new kernel
interface. This is true for any body trying to add some new
infrastructure to the kernel; you have to have an in-tree user of said
interface.
I mean, if some device manufacturer were to go to Red Hat's kernel
team, and say, "we need this interface for our uber expensive RDMA
interface card", and there was no in-kernel user for the interface, we
know what Red Hat would tell that device manufacturer, right? So why
is the SystemTap team trying to get an exception for utrace? It just
seems a little hypocritical.
So what about the ftrace user of utrace? Is that ready to be merged?
- Ted
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-21 12:04 ` Andrew Morton
` (2 preceding siblings ...)
2009-03-23 5:09 ` Roland McGrath
@ 2009-03-24 5:29 ` Ananth N Mavinakayanahalli
2009-03-24 5:54 ` Andrew Morton
3 siblings, 1 reply; 53+ messages in thread
From: Ananth N Mavinakayanahalli @ 2009-03-24 5:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Frank Ch. Eigler, Peter Zijlstra, linux-kernel, Rostedt, Steven,
utrace-devel, Linus Torvalds, Thomas Gleixner, Christoph Hellwig,
Jim Keniston
On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche@redhat.com> wrote:
> > On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
>
> I have strong memories of being traumatised by reading the uprobes code.
That was a long time ago wasn't it? :-)
That approach was a carry over from an implementation from dprobes that
used readdir hooks. Yes, that was not the most elegant approach, as such
has long been shelved.
> What's the story on all of that nowadays?
Utrace makes implementing uprobes more cleaner. We have a prototype that
implements uprobes over utrace. Its per process, doesn't use any
in-kernel hooks, etc. It currently has a kprobes like interface (needs a
kernel module), but it shouldn't be difficult to adapt it to use
utrace's user interfaces (syscalls?) when those come around. The current
generation of uprobes that has all the bells and whistles can be found at
http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=tree;f=runtime/uprobes2
However, there are aspects of the current uprobes that can be useful to
any other userspace tracer: instruction analysis, breakpoint insertion
and removal, single-stepping support. With these layered on top of
utrace, building userspace debug/trace tools that depend on utrace
should be easier, outside of ptrace.
Work is currently on to factor these layers out. The intention is to
upstream all the bits required for userspace tracing once utrace gets
in, along with an easy to use interface for userspace developers
(a /proc or /debugfs interface?) -- one should be able to use it on
its own or with SystemTap, whatever they prefer. Details are still hazy
at the moment.
But, utrace is the foundation to do all of that.
Ananth
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-24 5:29 ` Ananth N Mavinakayanahalli
@ 2009-03-24 5:54 ` Andrew Morton
2009-03-24 6:10 ` Ananth N Mavinakayanahalli
0 siblings, 1 reply; 53+ messages in thread
From: Andrew Morton @ 2009-03-24 5:54 UTC (permalink / raw)
To: ananth
Cc: Frank Ch. Eigler, Peter Zijlstra, linux-kernel, Rostedt, Steven,
utrace-devel, Linus Torvalds, Thomas Gleixner, Christoph Hellwig,
Jim Keniston
On Tue, 24 Mar 2009 10:59:26 +0530 Ananth N Mavinakayanahalli <ananth@in.ibm.com> wrote:
> On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> > On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche@redhat.com> wrote:
> > > On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> >
> > I have strong memories of being traumatised by reading the uprobes code.
>
> That was a long time ago wasn't it? :-)
>
> That approach was a carry over from an implementation from dprobes that
> used readdir hooks. Yes, that was not the most elegant approach, as such
> has long been shelved.
>
> > What's the story on all of that nowadays?
>
> Utrace makes implementing uprobes more cleaner. We have a prototype that
> implements uprobes over utrace. Its per process, doesn't use any
> in-kernel hooks, etc. It currently has a kprobes like interface (needs a
> kernel module), but it shouldn't be difficult to adapt it to use
> utrace's user interfaces (syscalls?) when those come around. The current
> generation of uprobes that has all the bells and whistles can be found at
> http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=tree;f=runtime/uprobes2
>
> However, there are aspects of the current uprobes that can be useful to
> any other userspace tracer: instruction analysis, breakpoint insertion
> and removal, single-stepping support. With these layered on top of
> utrace, building userspace debug/trace tools that depend on utrace
> should be easier, outside of ptrace.
>
> Work is currently on to factor these layers out. The intention is to
> upstream all the bits required for userspace tracing once utrace gets
> in, along with an easy to use interface for userspace developers
> (a /proc or /debugfs interface?) -- one should be able to use it on
> its own or with SystemTap, whatever they prefer. Details are still hazy
> at the moment.
>
> But, utrace is the foundation to do all of that.
>
The sticking point was uprobes's modification of live pagecache. We said
"ick, COW the pages" and you said "too expensive". And there things
remained.
Is that all going to happen again?
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-24 5:54 ` Andrew Morton
@ 2009-03-24 6:10 ` Ananth N Mavinakayanahalli
0 siblings, 0 replies; 53+ messages in thread
From: Ananth N Mavinakayanahalli @ 2009-03-24 6:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Frank Ch. Eigler, Peter Zijlstra, linux-kernel, Rostedt, Steven,
utrace-devel, Linus Torvalds, Thomas Gleixner, Christoph Hellwig,
Jim Keniston
On Mon, Mar 23, 2009 at 10:54:09PM -0700, Andrew Morton wrote:
> On Tue, 24 Mar 2009 10:59:26 +0530 Ananth N Mavinakayanahalli <ananth@in.ibm.com> wrote:
>
> > On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
> > > On Sat, 21 Mar 2009 07:51:41 -0400 "Frank Ch. Eigler" <fche@redhat.com> wrote:
> > > > On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
> > >
> > > I have strong memories of being traumatised by reading the uprobes code.
> >
> > That was a long time ago wasn't it? :-)
> >
> > That approach was a carry over from an implementation from dprobes that
> > used readdir hooks. Yes, that was not the most elegant approach, as such
> > has long been shelved.
> >
> > > What's the story on all of that nowadays?
> >
> > Utrace makes implementing uprobes more cleaner. We have a prototype that
> > implements uprobes over utrace. Its per process, doesn't use any
> > in-kernel hooks, etc. It currently has a kprobes like interface (needs a
> > kernel module), but it shouldn't be difficult to adapt it to use
> > utrace's user interfaces (syscalls?) when those come around. The current
> > generation of uprobes that has all the bells and whistles can be found at
> > http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=tree;f=runtime/uprobes2
> >
> > However, there are aspects of the current uprobes that can be useful to
> > any other userspace tracer: instruction analysis, breakpoint insertion
> > and removal, single-stepping support. With these layered on top of
> > utrace, building userspace debug/trace tools that depend on utrace
> > should be easier, outside of ptrace.
> >
> > Work is currently on to factor these layers out. The intention is to
> > upstream all the bits required for userspace tracing once utrace gets
> > in, along with an easy to use interface for userspace developers
> > (a /proc or /debugfs interface?) -- one should be able to use it on
> > its own or with SystemTap, whatever they prefer. Details are still hazy
> > at the moment.
> >
> > But, utrace is the foundation to do all of that.
> >
>
> The sticking point was uprobes's modification of live pagecache. We said
> "ick, COW the pages" and you said "too expensive". And there things
> remained.
>
> Is that all going to happen again?
No. All modifications are via access_process_vm().
Ananth
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-23 21:44 ` Theodore Tso
@ 2009-03-30 22:18 ` Andrew Morton
2009-03-30 22:52 ` Frank Ch. Eigler
2009-03-31 9:17 ` Peter Zijlstra
0 siblings, 2 replies; 53+ messages in thread
From: Andrew Morton @ 2009-03-30 22:18 UTC (permalink / raw)
To: Theodore Tso
Cc: oleg, adobriyan, mingo, torvalds, fche, roland, rostedt,
utrace-devel, linux-kernel, a.p.zijlstra, tglx
So we need to work out what to do about utrace and I feel a need to hit
the reset button on all this. Largely because I've forgotten
everything and it was all confusing anyway.
Could those who object to utrace please pipe up and summarise their
reasons?
Just to kick the can down the road a bit I merged the first two
patches. The ftrace patch merged about as (un)successfully as one would
expect.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-30 22:18 ` Andrew Morton
@ 2009-03-30 22:52 ` Frank Ch. Eigler
2009-03-31 9:17 ` Peter Zijlstra
1 sibling, 0 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-30 22:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Theodore Tso, oleg, adobriyan, mingo, torvalds, roland, rostedt,
utrace-devel, linux-kernel, a.p.zijlstra, tglx
Hi -
On Mon, Mar 30, 2009 at 03:18:44PM -0700, Andrew Morton wrote:
> So we need to work out what to do about utrace and I feel a need to hit
> the reset button on all this. [...]
Thanks.
> [...] The ftrace patch merged about as (un)successfully as one would
A new version against -tip is coming by in a few days.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-30 22:18 ` Andrew Morton
2009-03-30 22:52 ` Frank Ch. Eigler
@ 2009-03-31 9:17 ` Peter Zijlstra
2009-03-31 11:27 ` Peter Zijlstra
` (2 more replies)
1 sibling, 3 replies; 53+ messages in thread
From: Peter Zijlstra @ 2009-03-31 9:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Theodore Tso, oleg, adobriyan, mingo, torvalds, fche, roland,
rostedt, utrace-devel, linux-kernel, tglx, Christoph Hellwig,
Jeff Dike
On Mon, 2009-03-30 at 15:18 -0700, Andrew Morton wrote:
> So we need to work out what to do about utrace and I feel a need to hit
> the reset button on all this. Largely because I've forgotten
> everything and it was all confusing anyway.
Right, from my POV something like utrace is desirable, since its
basically a huge multiplexer for the debugger state, eventually allowing
us to have multiple debuggers attached to the same process.
So in that respect its a very nice feature.
> Could those who object to utrace please pipe up and summarise their
> reasons?
Christoph used to have an opinion on this matter, so I've added him to
the CC.
Last time when I looked at the code, it needed a bit more care and
comments wrt lifetimes and such. I know Roland has done a lot on that
front -- so I'll need to re-inspect.
As to in-kernel users, currently we only have ptrace, and no full
conversion to utrace is in a mergeable shape afaik.
UML (Jeff CC'ed) might want to use this.
I know the Systemtap people need this (fche). But that isn't really
moving towards mainline any time soon afaict.
Then there is this little thing called frysk which uses it, no idea what
kind of kernel space that needs, nor where it lives -- or for that
matter, wth it really does ;-)
Anyway, long story short, once people have had a little time to go over
the code, and a few in-kernel users are lined-up, I think we should
consider merging it.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-31 9:17 ` Peter Zijlstra
@ 2009-03-31 11:27 ` Peter Zijlstra
2009-03-31 11:38 ` Frank Ch. Eigler
2009-03-31 16:25 ` Christoph Hellwig
2 siblings, 0 replies; 53+ messages in thread
From: Peter Zijlstra @ 2009-03-31 11:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Theodore Tso, oleg, adobriyan, mingo, torvalds, fche, roland,
rostedt, utrace-devel, linux-kernel, tglx, Christoph Hellwig,
Jeff Dike
On Tue, 2009-03-31 at 11:17 +0200, Peter Zijlstra wrote:
> On Mon, 2009-03-30 at 15:18 -0700, Andrew Morton wrote:
> > So we need to work out what to do about utrace and I feel a need to hit
> > the reset button on all this. Largely because I've forgotten
> > everything and it was all confusing anyway.
>
> Right, from my POV something like utrace is desirable, since its
> basically a huge multiplexer for the debugger state, eventually allowing
> us to have multiple debuggers attached to the same process.
>
> So in that respect its a very nice feature.
>
> > Could those who object to utrace please pipe up and summarise their
> > reasons?
>
> Christoph used to have an opinion on this matter, so I've added him to
> the CC.
>
> Last time when I looked at the code, it needed a bit more care and
> comments wrt lifetimes and such. I know Roland has done a lot on that
> front -- so I'll need to re-inspect.
>
> As to in-kernel users, currently we only have ptrace, and no full
> conversion to utrace is in a mergeable shape afaik.
>
> UML (Jeff CC'ed) might want to use this.
>
> I know the Systemtap people need this (fche). But that isn't really
> moving towards mainline any time soon afaict.
>
> Then there is this little thing called frysk which uses it, no idea what
> kind of kernel space that needs, nor where it lives -- or for that
> matter, wth it really does ;-)
And Frank reminded me we have an ftrace tracer that utilizes utrace.
> Anyway, long story short, once people have had a little time to go over
> the code, and a few in-kernel users are lined-up, I think we should
> consider merging it.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-31 9:17 ` Peter Zijlstra
2009-03-31 11:27 ` Peter Zijlstra
@ 2009-03-31 11:38 ` Frank Ch. Eigler
2009-03-31 16:25 ` Christoph Hellwig
2 siblings, 0 replies; 53+ messages in thread
From: Frank Ch. Eigler @ 2009-03-31 11:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrew Morton, Theodore Tso, oleg, adobriyan, mingo, torvalds,
roland, rostedt, utrace-devel, linux-kernel, tglx,
Christoph Hellwig, Jeff Dike
Hi -
On Tue, Mar 31, 2009 at 11:17:42AM +0200, Peter Zijlstra wrote:
> [...] Right, from my POV something like utrace is desirable, since
> its basically a huge multiplexer for the debugger state, eventually
> allowing us to have multiple debuggers attached to the same process.
> [...]
Right.
> Then there is this little thing called frysk which uses it, no idea
> what kind of kernel space that needs, nor where it lives -- or for
> that matter, wth it really does ;-)
Frysk was to be a first user of such an improved ptrace(2) API in
order to do the sort of background / multiply-connected debugging, but
that project has been on indefinite hold for about a year. Instead,
there are experiments under way to extend gdb's backend for that
capability.
- FChE
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-31 9:17 ` Peter Zijlstra
2009-03-31 11:27 ` Peter Zijlstra
2009-03-31 11:38 ` Frank Ch. Eigler
@ 2009-03-31 16:25 ` Christoph Hellwig
2009-03-31 20:54 ` Roland McGrath
2 siblings, 1 reply; 53+ messages in thread
From: Christoph Hellwig @ 2009-03-31 16:25 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrew Morton, Theodore Tso, oleg, adobriyan, mingo, torvalds,
fche, roland, rostedt, utrace-devel, linux-kernel, tglx,
Christoph Hellwig, Jeff Dike
On Tue, Mar 31, 2009 at 11:17:42AM +0200, Peter Zijlstra wrote:
> > Could those who object to utrace please pipe up and summarise their
> > reasons?
>
> Christoph used to have an opinion on this matter, so I've added him to
> the CC.
I've never objected utrace per see, quite contrary I think it's a useful
abstraction. I did have objection over various implementation details
which should be sorted out now (have to take a look again to make sure).
I do have a really large objection of merging the current messy double
ptrace implementation. If current utrace based ptrace isn't 100% ready
there's absolutely no point in merging it. Other user would be even
better, e.g. the seccomp rewrite.
^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2
2009-03-31 16:25 ` Christoph Hellwig
@ 2009-03-31 20:54 ` Roland McGrath
0 siblings, 0 replies; 53+ messages in thread
From: Roland McGrath @ 2009-03-31 20:54 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Peter Zijlstra, Andrew Morton, Theodore Tso, oleg, adobriyan,
mingo, torvalds, fche, rostedt, utrace-devel, linux-kernel, tglx,
Jeff Dike
> I do have a really large objection of merging the current messy double
> ptrace implementation. If current utrace based ptrace isn't 100% ready
> there's absolutely no point in merging it.
There is no "current" utrace-ptrace implementation. I haven't proposed
one for merging. When one is ready and working, we can discuss its actual
technical details then.
> Other user would be even better, e.g. the seccomp rewrite.
The seccomp rewrite is a very simple user for which I have a prototype
patch. (It needs testing, but that should be easy enough.) The only
real complexity there is in deciding how to merge those changes.
Its components are:
* clean up Kconfig
* remove old arch/asm hooks
** mips
** powerpc
** sh
** sparc
** x86
* replace kernel/seccomp.c with utrace-based one
Except for the first one, doing it in small incremental changes would
leave some intermediate states with no seccomp feature usable in the
tree. (And, of course, CONFIG_SECCOMP will require CONFIG_UTRACE
thereafter.) Please advise on how many pieces to slice it into and
how to stage the merging.
Thanks,
Roland
^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2009-03-31 20:57 UTC | newest]
Thread overview: 53+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-21 1:39 [PATCH 0/3] utrace Roland McGrath
2009-03-21 1:41 ` [PATCH 1/3] signals: tracehook_notify_jctl change Roland McGrath
2009-03-21 1:41 ` [PATCH 2/3] utrace core Roland McGrath
2009-03-21 8:49 ` Andrew Morton
2009-03-21 14:08 ` Renzo Davoli
2009-03-21 14:34 ` Ingo Molnar
2009-03-21 16:37 ` Renzo Davoli
2009-03-21 16:44 ` Ingo Molnar
2009-03-23 4:34 ` Roland McGrath
2009-03-23 4:35 ` Roland McGrath
2009-03-23 10:57 ` Will Newton
2009-03-21 1:42 ` [PATCH 3/3] utrace-based ftrace "process" engine, v2 Roland McGrath
2009-03-21 7:43 ` Ingo Molnar
2009-03-21 8:39 ` Andrew Morton
2009-03-21 9:12 ` Ingo Molnar
2009-03-21 11:19 ` Andrew Morton
2009-03-21 11:51 ` Frank Ch. Eigler
2009-03-21 12:04 ` Andrew Morton
2009-03-21 12:57 ` Frank Ch. Eigler
2009-03-21 15:45 ` Ingo Molnar
2009-03-21 20:35 ` Diego Calleja
2009-03-22 12:17 ` Ingo Molnar
2009-03-21 21:34 ` Andrew Morton
2009-03-21 21:51 ` Frank Ch. Eigler
2009-03-21 22:02 ` Linus Torvalds
2009-03-21 22:20 ` Frank Ch. Eigler
2009-03-21 22:37 ` Alexey Dobriyan
2009-03-21 23:38 ` Frank Ch. Eigler
2009-03-22 10:25 ` Ingo Molnar
2009-03-23 5:33 ` Roland McGrath
2009-03-23 5:20 ` Roland McGrath
2009-03-22 12:37 ` Ingo Molnar
2009-03-23 13:48 ` Alexey Dobriyan
2009-03-23 15:14 ` Oleg Nesterov
2009-03-23 21:44 ` Theodore Tso
2009-03-30 22:18 ` Andrew Morton
2009-03-30 22:52 ` Frank Ch. Eigler
2009-03-31 9:17 ` Peter Zijlstra
2009-03-31 11:27 ` Peter Zijlstra
2009-03-31 11:38 ` Frank Ch. Eigler
2009-03-31 16:25 ` Christoph Hellwig
2009-03-31 20:54 ` Roland McGrath
2009-03-21 21:48 ` Frank Ch. Eigler
2009-03-22 12:08 ` Ingo Molnar
2009-03-22 12:53 ` Ingo Molnar
2009-03-23 20:25 ` Frank Ch. Eigler
2009-03-23 20:39 ` Linus Torvalds
2009-03-23 5:09 ` Roland McGrath
2009-03-24 5:29 ` Ananth N Mavinakayanahalli
2009-03-24 5:54 ` Andrew Morton
2009-03-24 6:10 ` Ananth N Mavinakayanahalli
2009-03-23 4:49 ` Roland McGrath
2009-03-23 6:34 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox