All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC,PATCH 14/14] utrace core
@ 2009-11-24 20:02 Oleg Nesterov
  2009-11-24 20:32 ` Andi Kleen
  2009-12-01 19:54 ` Peter Zijlstra
  0 siblings, 2 replies; 37+ messages in thread
From: Oleg Nesterov @ 2009-11-24 20:02 UTC (permalink / raw)
  To: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Peter Zijlstra, Roland McGrath
  Cc: linux-kernel, utrace-devel

From: Roland McGrath <roland@redhat.com>

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. It can only be
enabled on machines that have all the prerequisites and select
CONFIG_HAVE_ARCH_TRACEHOOK.

If CONFIG_UTRACE is set ptrace uses the utrace facilities, it can play
nicely with other utrace-based things tracing the same threads.

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---

 Documentation/DocBook/Makefile    |    2 
 Documentation/DocBook/utrace.tmpl |  590 +++++++++
 fs/proc/array.c                   |    3 
 include/linux/sched.h             |    5 
 include/linux/tracehook.h         |   91 +
 include/linux/utrace.h            |  729 +++++++++++
 init/Kconfig                      |    9 
 kernel/fork.c                     |    3 
 kernel/Makefile                   |    1 
 kernel/utrace.c                   | 2430 ++++++++++++++++++++++++++++++++++++++
 10 files changed, 3861 insertions(+), 2 deletions(-)

--- V1/Documentation/DocBook/Makefile~14_UTRACE	2009-11-24 20:27:22.000000000 +0100
+++ V1/Documentation/DocBook/Makefile	2009-11-24 20:30:17.000000000 +0100
@@ -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 \
--- /dev/null	2009-11-24 16:51:11.614043008 +0100
+++ V1/Documentation/DocBook/utrace.tmpl	2009-11-24 20:30:17.000000000 +0100
@@ -0,0 +1,590 @@
+<?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>&lt;linux/utrace.h&gt;</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.  For most events, 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>
+
+  <para>
+    The <constant>UTRACE_EVENT(SYSCALL_ENTRY)</constant> event is a special
+    case.  While other events happen in the kernel when it will return to
+    user mode soon, this event happens when entering the kernel before it
+    will proceed with the work requested from user mode.  Because of this
+    difference, the <function>report_syscall_entry</function> callback is
+    special in two ways.  For this event, engines are called in reverse of
+    the normal order (this includes the <function>report_quiesce</function>
+    call that precedes a <function>report_syscall_entry</function> call).
+    This preserves the semantics that the last engine to attach is called
+    "closest to user mode"--the engine that is first to see a thread's user
+    state when it enters the kernel is also the last to see that state when
+    the thread returns to user mode.  For the same reason, if these
+    callbacks use <constant>UTRACE_STOP</constant> (see the next section),
+    the thread stops immediately after callbacks rather than only when it's
+    ready to return to user mode; when allowed to resume, it will actually
+    attempt the system call indicated by the register values at that time.
+  </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>&lt;linux/utrace.h&gt;</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>&lt;linux/regset.h&gt;</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>&lt;linux/ptrace.h&gt;</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>&lt;asm/syscall.h&gt;</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>&lt;linux/tracehook.h&gt;</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>&lt;asm/ptrace.h&gt;</filename></title>
+
+<para>
+  An arch defines these in <filename>&lt;asm/ptrace.h&gt;</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>&lt;asm/syscall.h&gt;</filename></title>
+
+  <para>
+    An arch provides <filename>&lt;asm/syscall.h&gt;</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>&lt;linux/tracehook.h&gt;</filename></title>
+
+  <para>
+    An arch must define <constant>TIF_NOTIFY_RESUME</constant>
+    and <constant>TIF_SYSCALL_TRACE</constant>
+    in its <filename>&lt;asm/thread_info.h&gt;</filename>.
+    The arch code must call the following functions, all declared
+    in <filename>&lt;linux/tracehook.h&gt;</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>
--- V1/fs/proc/array.c~14_UTRACE	2009-11-24 20:27:22.000000000 +0100
+++ V1/fs/proc/array.c	2009-11-24 20:30:17.000000000 +0100
@@ -82,6 +82,7 @@
 #include <linux/pid_namespace.h>
 #include <linux/ptrace.h>
 #include <linux/tracehook.h>
+#include <linux/utrace.h>
 #include <linux/swapops.h>
 
 #include <asm/pgtable.h>
@@ -189,6 +190,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);
--- V1/include/linux/sched.h~14_UTRACE	2009-11-24 20:30:16.000000000 +0100
+++ V1/include/linux/sched.h	2009-11-24 20:30:17.000000000 +0100
@@ -1393,6 +1393,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;
--- V1/include/linux/tracehook.h~14_UTRACE	2009-11-24 20:30:15.000000000 +0100
+++ V1/include/linux/tracehook.h	2009-11-24 20:30:17.000000000 +0100
@@ -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,9 @@ 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);
+
 	if (step && (task_ptrace(current) & PT_PTRACED)) {
 		siginfo_t info;
 		user_single_step_siginfo(current, regs, &info);
@@ -201,6 +210,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);
@@ -218,10 +229,37 @@ 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);
 }
 
 /**
+ * tracehook_init_task - task_struct has just been copied
+ * @task:		new &struct task_struct just copied from parent
+ *
+ * Called from do_fork() when @task has just been duplicated.
+ * After this, @task will be passed to tracehook_free_task()
+ * even if the rest of its setup fails before it is fully created.
+ */
+static inline void tracehook_init_task(struct task_struct *task)
+{
+	utrace_init_task(task);
+}
+
+/**
+ * tracehook_free_task - task_struct is being freed
+ * @task:		dead &struct task_struct being freed
+ *
+ * Called from free_task() when @task is no longer in use.
+ */
+static inline void tracehook_free_task(struct task_struct *task)
+{
+	if (task_utrace_struct(task))
+		utrace_free_task(task);
+}
+
+/**
  * tracehook_prepare_clone - prepare for new child to be cloned
  * @clone_flags:	%CLONE_* flags from clone/fork/vfork system call
  *
@@ -285,6 +323,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(task_ptrace(child))) {
 		/*
 		 * It doesn't matter who attached/attaching to this
@@ -317,6 +357,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);
 }
@@ -351,6 +394,10 @@ static inline void tracehook_report_vfor
  */
 static inline void tracehook_prepare_release_task(struct task_struct *task)
 {
+	/* see utrace_add_engine() about this barrier */
+	smp_mb();
+	if (task_utrace_flags(task))
+		utrace_release_task(task);
 }
 
 /**
@@ -365,6 +412,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);
 }
 
 /**
@@ -386,6 +434,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 && (task_ptrace(current) & PT_PTRACED))
 		ptrace_notify(SIGTRAP);
 }
@@ -403,6 +453,8 @@ static inline void tracehook_signal_hand
 static inline int tracehook_consider_ignored_signal(struct task_struct *task,
 						    int sig)
 {
+	if (unlikely(task_utrace_flags(task) & UTRACE_EVENT(SIGNAL_IGN)))
+		return 1;
 	return (task_ptrace(task) & PT_PTRACED) != 0;
 }
 
@@ -422,6 +474,9 @@ static inline int tracehook_consider_ign
 static inline int tracehook_consider_fatal_signal(struct task_struct *task,
 						  int sig)
 {
+	if (unlikely(task_utrace_flags(task) & (UTRACE_EVENT(SIGNAL_TERM) |
+						UTRACE_EVENT(SIGNAL_CORE))))
+		return 1;
 	return (task_ptrace(task) & PT_PTRACED) != 0;
 }
 
@@ -436,6 +491,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;
 }
 
@@ -465,6 +522,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;
 }
 
@@ -492,6 +551,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 ?: task_ptrace(current) ? why : 0;
 }
 
@@ -502,6 +563,8 @@ static inline int tracehook_notify_jctl(
  */
 static inline void tracehook_finish_jctl(void)
 {
+	if (task_utrace_flags(current))
+		utrace_finish_stop();
 }
 
 #define DEATH_REAP			-1
@@ -524,6 +587,8 @@ static inline void tracehook_finish_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_detached(task))
 		return task->ptrace ? SIGCHLD : DEATH_REAP;
 
@@ -560,6 +625,20 @@ static inline void tracehook_report_deat
 					  int signal, void *death_cookie,
 					  int group_dead)
 {
+	/*
+	 * This barrier ensures that our caller's setting of
+	 * @task->exit_state precedes checking @task->utrace_flags here.
+	 * If utrace_set_events() was just called to enable
+	 * UTRACE_EVENT(DEATH), then we are obliged to call
+	 * utrace_report_death() and not miss it.  utrace_set_events()
+	 * uses tasklist_lock to synchronize enabling the bit with the
+	 * actual change to @task->exit_state, but we need this barrier
+	 * to be sure we see a flags change made just before our caller
+	 * took the tasklist_lock.
+	 */
+	smp_mb();
+	if (task_utrace_flags(task) & _UTRACE_DEATH_EVENTS)
+		utrace_report_death(task, death_cookie, group_dead, signal);
 }
 
 #ifdef TIF_NOTIFY_RESUME
@@ -589,10 +668,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 */
 
--- /dev/null	2009-11-24 16:51:11.614043008 +0100
+++ V1/include/linux/utrace.h	2009-11-24 20:30:17.000000000 +0100
@@ -0,0 +1,729 @@
+/*
+ * 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.
+ */
+void utrace_free_task(struct task_struct *)
+	__attribute__((weak));
+bool utrace_interrupt_pending(void)
+	__attribute__((weak));
+void utrace_resume(struct task_struct *, struct pt_regs *)
+	__attribute__((weak));
+void utrace_finish_stop(void)
+	__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)
+{
+	struct utrace *utrace;
+
+	/*
+	 * This barrier ensures that any prior load of task->utrace_flags
+	 * is ordered before this load of task->utrace.  We use those
+	 * utrace_flags checks in the hot path to decide to call into
+	 * the utrace code.  The first attach installs task->utrace before
+	 * setting task->utrace_flags nonzero, with a barrier between.
+	 * See utrace_task_alloc().
+	 */
+	smp_rmb();
+	utrace = task->utrace;
+
+	smp_read_barrier_depends(); /* See utrace_task_alloc().  */
+	return utrace;
+}
+
+static inline void utrace_init_task(struct task_struct *task)
+{
+	task->utrace_flags = 0;
+	task->utrace = NULL;
+}
+
+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	20090421
+
+/**
+ * enum utrace_resume_action - engine's choice of action for a traced task
+ * @UTRACE_STOP:		Stay quiescent after callbacks.
+ * @UTRACE_INTERRUPT:		Make @report_signal() callback soon.
+ * @UTRACE_REPORT:		Make some 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_INTERRUPT,
+	UTRACE_REPORT,
+	UTRACE_SINGLESTEP,
+	UTRACE_BLOCKSTEP,
+	UTRACE_RESUME,
+	UTRACE_DETACH
+};
+#define	UTRACE_RESUME_MASK	0x07
+
+/**
+ * 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
+#define	UTRACE_SYSCALL_RESUMED	0x100 /* Flag, report_syscall_entry() repeats */
+
+/**
+ * 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;
+	void (*release)(void *);
+	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 this case, another
+ * @report_syscall_entry callback will follow after @task resumes if
+ * %UTRACE_REPORT or %UTRACE_INTERRUPT was returned by some callback
+ * or passed to utrace_control().  In a second or later callback,
+ * %UTRACE_SYSCALL_RESUMED is set in the @action argument to indicate
+ * a repeat callback still waiting to attempt the same system call
+ * invocation.  This repeat callback gives each engine an opportunity
+ * to reexamine registers another engine might have changed while
+ * @task was held in %UTRACE_STOP.
+ *
+ * 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().
+ *	See above about the %UTRACE_SYSCALL_RESUMED flag in @action.
+ *	Use %UTRACE_REPORT in the return value to guarantee you get
+ *	another callback (with %UTRACE_SYSCALL_RESUMED flag) in case
+ *	@task stops with %UTRACE_STOP before attempting the system call.
+ *
+ * @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.
+ *
+ * @release:
+ *	If not %NULL, this is called after the last utrace_engine_put()
+ *	call for a &struct utrace_engine, which could be implicit after
+ *	a %UTRACE_DETACH return from another callback.  Its argument is
+ *	the engine's @data member.
+ */
+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);
+	void (*release)(void *data);
+};
+
+/**
+ * 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 */
--- V1/init/Kconfig~14_UTRACE	2009-11-24 20:27:22.000000000 +0100
+++ V1/init/Kconfig	2009-11-24 20:46:05.000000000 +0100
@@ -295,6 +295,15 @@ config AUDIT
 	  logging of avc messages output).  Does not do system-call
 	  auditing without CONFIG_AUDITSYSCALL.
 
+config 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.
+
 config AUDITSYSCALL
 	bool "Enable system-call auditing support"
 	depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH)
--- V1/kernel/fork.c~14_UTRACE	2009-11-24 20:27:22.000000000 +0100
+++ V1/kernel/fork.c	2009-11-24 20:30:17.000000000 +0100
@@ -152,6 +152,7 @@ void free_task(struct task_struct *tsk)
 	free_thread_info(tsk->stack);
 	rt_mutex_debug_task_free(tsk);
 	ftrace_graph_exit_task(tsk);
+	tracehook_free_task(tsk);
 	free_task_struct(tsk);
 }
 EXPORT_SYMBOL(free_task);
@@ -1018,6 +1019,8 @@ static struct task_struct *copy_process(
 	if (!p)
 		goto fork_out;
 
+	tracehook_init_task(p);
+
 	ftrace_graph_init_task(p);
 
 	rt_mutex_init_task(p);
--- V1/kernel/Makefile~14_UTRACE	2009-11-24 20:30:17.000000000 +0100
+++ V1/kernel/Makefile	2009-11-24 20:30:17.000000000 +0100
@@ -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_UTRACE) += ptrace-utrace.o
 obj-$(CONFIG_AUDIT) += audit.o auditfilter.o audit_watch.o
 obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
--- /dev/null	2009-11-24 16:51:11.614043008 +0100
+++ V1/kernel/utrace.c	2009-11-24 20:30:17.000000000 +0100
@@ -0,0 +1,2430 @@
+/*
+ * 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>
+
+
+/*
+ * Per-thread structure private to utrace implementation.
+ * If task_struct.utrace_flags is nonzero, task_struct.utrace
+ * has always been allocated first.  Once allocated, it is
+ * never freed until free_task().
+ *
+ * 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.
+ */
+struct utrace {
+	spinlock_t lock;
+	struct list_head attached, attaching;
+
+	struct task_struct *cloning;
+
+	struct utrace_engine *reporting;
+
+	enum utrace_resume_action resume:3;
+	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 */
+	unsigned int pending_attach:1; /* need splice_attaching() */
+};
+
+static struct kmem_cache *utrace_cachep;
+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_cachep = KMEM_CACHE(utrace, SLAB_PANIC);
+	utrace_engine_cachep = KMEM_CACHE(utrace_engine, SLAB_PANIC);
+	return 0;
+}
+module_init(utrace_init);
+
+/*
+ * Set up @task.utrace for the first time.  We can have races
+ * between two utrace_attach_task() calls here.  The task_lock()
+ * governs installing the new pointer.  If another one got in first,
+ * we just punt the new one we allocated.
+ *
+ * This returns false only in case of a memory allocation failure.
+ */
+static bool utrace_task_alloc(struct task_struct *task)
+{
+	struct utrace *utrace = kmem_cache_zalloc(utrace_cachep, GFP_KERNEL);
+	if (unlikely(!utrace))
+		return false;
+	spin_lock_init(&utrace->lock);
+	INIT_LIST_HEAD(&utrace->attached);
+	INIT_LIST_HEAD(&utrace->attaching);
+	utrace->resume = UTRACE_RESUME;
+	task_lock(task);
+	if (likely(!task->utrace)) {
+		/*
+		 * This barrier makes sure the initialization of the struct
+		 * precedes the installation of the pointer.  This pairs
+		 * with smp_read_barrier_depends() in task_utrace_struct().
+		 */
+		smp_wmb();
+		task->utrace = utrace;
+	}
+	task_unlock(task);
+	/*
+	 * That unlock after storing task->utrace acts as a memory barrier
+	 * ordering any subsequent task->utrace_flags store afterwards.
+	 * This pairs with smp_rmb() in task_utrace_struct().
+	 */
+	if (unlikely(task->utrace != utrace))
+		kmem_cache_free(utrace_cachep, utrace);
+	return true;
+}
+
+/*
+ * This is called via tracehook_free_task() from free_task()
+ * when @task is being deallocated.
+ */
+void utrace_free_task(struct task_struct *task)
+{
+	kmem_cache_free(utrace_cachep, task->utrace);
+}
+
+/*
+ * 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);
+	utrace->pending_attach = 0;
+}
+
+/*
+ * 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));
+	if (engine->release)
+		(*engine->release)(engine->data);
+	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;
+}
+
+/*
+ * 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) &&
+	    task_utrace_struct(current) &&
+	    task_utrace_struct(current)->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);
+
+	ret = -EEXIST;
+	if ((flags & UTRACE_ATTACH_EXCLUSIVE) &&
+	     unlikely(matching_engine(utrace, flags, ops, data)))
+		goto unlock;
+
+	/*
+	 * In case we had no engines before, make sure that
+	 * utrace_flags is not zero.
+	 */
+	ret = -ESRCH;
+	if (!target->utrace_flags) {
+		target->utrace_flags = UTRACE_EVENT(REAP);
+		/*
+		 * If we race with tracehook_prepare_release_task()
+		 * make sure that either it sees utrace_flags != 0
+		 * or we see exit_state == EXIT_DEAD.
+		 */
+		smp_mb();
+		if (unlikely(target->exit_state == EXIT_DEAD)) {
+			target->utrace_flags = 0;
+			goto unlock;
+		}
+	}
+
+	/*
+	 * Put the new engine on the pending ->attaching list.
+	 * Make sure it gets onto the ->attached list by the next
+	 * time it's examined.  Setting ->pending_attach ensures
+	 * that start_report() takes the lock and splices the lists
+	 * before the next new reporting pass.
+	 *
+	 * 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.
+	 */
+	list_add_tail(&engine->entry, &utrace->attaching);
+	utrace->pending_attach = 1;
+	ret = 0;
+unlock:
+	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.
+ *
+ * Calls with neither %UTRACE_ATTACH_MATCH_OPS nor %UTRACE_ATTACH_MATCH_DATA
+ * match the first among any engines attached to @target.  That means that
+ * %UTRACE_ATTACH_EXCLUSIVE in such a call fails with -%EEXIST if there
+ * are any engines on @target at all.
+ */
+struct utrace_engine *utrace_attach_task(
+	struct task_struct *target, int flags,
+	const struct utrace_engine_ops *ops, void *data)
+{
+	struct utrace *utrace = task_utrace_struct(target);
+	struct utrace_engine *engine;
+	int ret;
+
+	if (!(flags & UTRACE_ATTACH_CREATE)) {
+		if (unlikely(!utrace))
+			return ERR_PTR(-ENOENT);
+		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);
+
+	if (!utrace) {
+		if (unlikely(!utrace_task_alloc(target)))
+			return ERR_PTR(-ENOMEM);
+		utrace = task_utrace_struct(target);
+	}
+
+	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;
+	engine->release = ops->release;
+
+	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
+};
+
+/*
+ * 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 = task_utrace_struct(target);
+	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 and utrace->reap set.
+ * 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;
+
+	/* utrace_add_engine() checks ->utrace_flags != 0 */
+	target->utrace_flags = 0;
+	splice_attaching(utrace);
+
+	/*
+	 * Since we were called with @utrace->reap set, nobody can
+	 * set/clear UTRACE_EVENT(REAP) in @engine->flags or change
+	 * @engine->ops, and nobody can change @utrace->attached.
+	 */
+	spin_unlock(&utrace->lock);
+
+	list_for_each_entry_safe(engine, next, &utrace->attached, entry) {
+		if (engine->flags & UTRACE_EVENT(REAP))
+			engine->ops->report_reap(engine, target);
+
+		engine->ops = NULL;
+		engine->flags = 0;
+		list_del_init(&engine->entry);
+
+		utrace_engine_put(engine);
+	}
+}
+
+
+/*
+ * Called by release_task.
+ */
+void utrace_release_task(struct task_struct *target)
+{
+	struct utrace *utrace = task_utrace_struct(target);
+
+	spin_lock(&utrace->lock);
+
+	utrace->reap = 1;
+
+	/*
+	 * If 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.
+	 */
+
+	if (target->utrace_flags & _UTRACE_DEATH_EVENTS)
+		spin_unlock(&utrace->lock);
+	else
+		utrace_reap(target, utrace); /* Unlocks.  */
+}
+
+/*
+ * We use an extra bit in utrace_engine.flags past the event bits,
+ * to record whether the engine is keeping the target thread stopped.
+ *
+ * This bit is set in task_struct.utrace_flags whenever it is set in any
+ * engine's flags.  Only utrace_reset() resets it in utrace_flags.
+ */
+#define ENGINE_STOP		(1UL << _UTRACE_NEVENTS)
+
+static void mark_engine_wants_stop(struct task_struct *task,
+				   struct utrace_engine *engine)
+{
+	engine->flags |= ENGINE_STOP;
+	task->utrace_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 @events excludes some bits that were
+ * set before, this can return -%EINPROGRESS to indicate that @target
+ * may have been making some callback to @engine.  When this returns
+ * zero, you can be sure that no event callbacks you've disabled in
+ * @events can be made.  If @events only sets new bits that were not set
+ * before on @engine, then -%EINPROGRESS will never be returned.
+ *
+ * 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;
+	int ret;
+
+	/*
+	 * We just ignore the internal bit, so callers can use
+	 * engine->flags to seed bitwise ops for our argument.
+	 */
+	events &= ~ENGINE_STOP;
+
+	utrace = get_utrace_lock(target, engine, true);
+	if (unlikely(IS_ERR(utrace)))
+		return PTR_ERR(utrace);
+
+	old_utrace_flags = target->utrace_flags;
+	old_flags = engine->flags & ~ENGINE_STOP;
+
+	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 ((events & ~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 |= events;
+		read_unlock(&tasklist_lock);
+	}
+
+	engine->flags = events | (engine->flags & ENGINE_STOP);
+	target->utrace_flags |= events;
+
+	if ((events & UTRACE_EVENT_SYSCALL) &&
+	    !(old_utrace_flags & UTRACE_EVENT_SYSCALL))
+		set_tsk_thread_flag(target, TIF_SYSCALL_TRACE);
+
+	ret = 0;
+	if ((old_flags & ~events) && target != current &&
+	    !task_is_stopped_or_traced(target) && !target->exit_state) {
+		/*
+		 * 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)
+{
+	if (task_is_stopped(target)) {
+		/*
+		 * Stopped is considered quiescent; when it wakes up, it will
+		 * go through utrace_finish_stop() before doing anything else.
+		 */
+		spin_lock_irq(&target->sighand->siglock);
+		if (likely(task_is_stopped(target)))
+			__set_task_state(target, TASK_TRACED);
+		spin_unlock_irq(&target->sighand->siglock);
+	} else if (utrace->resume > UTRACE_REPORT) {
+		utrace->resume = UTRACE_REPORT;
+		set_notify_resume(target);
+	}
+
+	return task_is_traced(target);
+}
+
+/*
+ * 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 @target in either TASK_TRACED or dead.
+ */
+static void utrace_wakeup(struct task_struct *target, struct utrace *utrace)
+{
+	spin_lock_irq(&target->sighand->siglock);
+	if (target->signal->flags & SIGNAL_STOP_STOPPED ||
+	    target->signal->group_stop_count)
+		target->state = TASK_STOPPED;
+	else
+		wake_up_state(target, __TASK_TRACED);
+	spin_unlock_irq(&target->sighand->siglock);
+}
+
+/*
+ * 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.  Returns true if we're now fully detached.
+ *
+ * Called with @utrace->lock held, returns with it released.
+ * After this returns, @utrace might be freed if everything detached.
+ */
+static bool utrace_reset(struct task_struct *task, struct utrace *utrace)
+	__releases(utrace->lock)
+{
+	struct utrace_engine *engine, *next;
+	unsigned long flags = 0;
+	LIST_HEAD(detached);
+
+	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);
+		}
+	}
+
+	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);
+	} else if (!(flags & UTRACE_EVENT_SYSCALL) &&
+		   test_tsk_thread_flag(task, TIF_SYSCALL_TRACE)) {
+		clear_tsk_thread_flag(task, TIF_SYSCALL_TRACE);
+	}
+
+	if (!flags) {
+		/*
+		 * No more engines, cleared out the utrace.
+		 */
+		utrace->resume = UTRACE_RESUME;
+		utrace->signal_handler = 0;
+	}
+
+	if (task_is_traced(task) && !(flags & ENGINE_STOP))
+		/*
+		 * No more engines want it stopped.  Wake it up.
+		 */
+		utrace_wakeup(task, utrace);
+
+	/*
+	 * In theory spin_lock() doesn't imply rcu_read_lock().
+	 * Once we clear ->utrace_flags this task_struct can go away
+	 * because tracehook_prepare_release_task() path does not take
+	 * utrace->lock when ->utrace_flags == 0.
+	 */
+	rcu_read_lock();
+	task->utrace_flags = flags;
+	spin_unlock(&utrace->lock);
+	rcu_read_unlock();
+
+	put_detached_list(&detached);
+
+	return !flags;
+}
+
+void utrace_finish_stop(void)
+{
+	/*
+	 * If we were task_is_traced() and then SIGKILL'ed, make
+	 * sure we do nothing until the tracer drops utrace->lock.
+	 */
+	if (unlikely(__fatal_signal_pending(current))) {
+		struct utrace *utrace = task_utrace_struct(current);
+		spin_unlock_wait(&utrace->lock);
+	}
+}
+
+/*
+ * 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 void utrace_stop(struct task_struct *task, struct utrace *utrace,
+			enum utrace_resume_action action)
+{
+relock:
+	spin_lock(&utrace->lock);
+
+	if (action < utrace->resume) {
+		/*
+		 * Ensure a reporting pass when we're resumed.
+		 */
+		utrace->resume = action;
+		if (action == UTRACE_INTERRUPT)
+			set_thread_flag(TIF_SIGPENDING);
+		else
+			set_thread_flag(TIF_NOTIFY_RESUME);
+	}
+
+	/*
+	 * If the ENGINE_STOP bit is clear in utrace_flags, that means
+	 * utrace_reset() ran after we processed some UTRACE_STOP return
+	 * values from callbacks to get here.  If all engines have detached
+	 * or resumed us, we don't stop.  This check doesn't require
+	 * siglock, but it should follow the interrupt/report bookkeeping
+	 * steps (this can matter for UTRACE_RESUME but not UTRACE_DETACH).
+	 */
+	if (unlikely(!(task->utrace_flags & ENGINE_STOP))) {
+		utrace_reset(task, utrace);
+		if (task->utrace_flags & ENGINE_STOP)
+			goto relock;
+		return;
+	}
+
+	/*
+	 * 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_irq(&task->sighand->siglock);
+
+	if (unlikely(__fatal_signal_pending(task))) {
+		spin_unlock_irq(&task->sighand->siglock);
+		spin_unlock(&utrace->lock);
+		return;
+	}
+
+	__set_current_state(TASK_TRACED);
+
+	/*
+	 * If there is a group stop in progress,
+	 * we must participate in the bookkeeping.
+	 */
+	if (unlikely(task->signal->group_stop_count) &&
+			!--task->signal->group_stop_count)
+		task->signal->flags = SIGNAL_STOP_STOPPED;
+
+	spin_unlock_irq(&task->sighand->siglock);
+	spin_unlock(&utrace->lock);
+
+	/*
+	 * If ptrace is among the reasons for this stop, do its
+	 * notification now.  This could not just be done in
+	 * ptrace's own event report callbacks because it has to
+	 * be done after we are in TASK_TRACED.  This makes the
+	 * synchronization with ptrace_do_wait() work right.
+	 */
+	ptrace_notify_stop(task);
+
+	schedule();
+
+	utrace_finish_stop();
+
+	/*
+	 * 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();
+
+	/*
+	 * 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);
+}
+
+/*
+ * 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.
+ *
+ * Since this is meaningless unless @report_quiesce callbacks will
+ * be made, it returns -%EINVAL if @engine lacks %UTRACE_EVENT(%QUIESCE).
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * Since this is not robust unless @report_quiesce callbacks will
+ * be made, it returns -%EINVAL if @engine lacks %UTRACE_EVENT(%QUIESCE).
+ *
+ * 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.
+ *
+ * Since this is not robust unless @report_quiesce callbacks will
+ * be made, it returns -%EINVAL if @engine lacks %UTRACE_EVENT(%QUIESCE).
+ *
+ * %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 reset;
+	int ret;
+
+	if (unlikely(action > UTRACE_DETACH))
+		return -EINVAL;
+
+	/*
+	 * This is a sanity check for a programming error in the caller.
+	 * Their request can only work properly in all cases by relying on
+	 * a follow-up callback, but they didn't set one up!  This check
+	 * doesn't do locking, but it shouldn't matter.  The caller has to
+	 * be synchronously sure the callback is set up to be operating the
+	 * interface properly.
+	 */
+	if (action >= UTRACE_REPORT && action < UTRACE_RESUME &&
+	    unlikely(!(engine->flags & UTRACE_EVENT(QUIESCE))))
+		return -EINVAL;
+
+	utrace = get_utrace_lock(target, engine, true);
+	if (unlikely(IS_ERR(utrace)))
+		return PTR_ERR(utrace);
+
+	reset = task_is_traced(target);
+	ret = 0;
+
+	/*
+	 * ->exit_state can change under us, this doesn't matter.
+	 * We do not care about ->exit_state in fact, but we do
+	 * care about ->reap and ->death. If either flag is set,
+	 * we must also see ->exit_state != 0.
+	 */
+	if (unlikely(target->exit_state)) {
+		ret = utrace_control_dead(target, utrace, action);
+		if (ret) {
+			spin_unlock(&utrace->lock);
+			return ret;
+		}
+		reset = true;
+	}
+
+	switch (action) {
+	case UTRACE_STOP:
+		mark_engine_wants_stop(target, engine);
+		if (!reset && !utrace_do_stop(target, utrace))
+			ret = -EINPROGRESS;
+		reset = false;
+		break;
+
+	case UTRACE_DETACH:
+		if (engine_wants_stop(engine))
+			target->utrace_flags &= ~ENGINE_STOP;
+		mark_engine_detached(engine);
+		reset = reset || utrace_do_stop(target, utrace);
+		if (!reset) {
+			/*
+			 * 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;
+
+	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.
+		 */
+		clear_engine_wants_stop(engine);
+		if (likely(reset))
+			user_disable_single_step(target);
+		break;
+
+	case UTRACE_BLOCKSTEP:
+		/*
+		 * Resume from stopped, step one block.
+		 * We fall through to treat it like UTRACE_SINGLESTEP.
+		 */
+		if (unlikely(!arch_has_block_step())) {
+			WARN_ON(1);
+			action = UTRACE_SINGLESTEP;
+		}
+
+	case UTRACE_SINGLESTEP:
+		/*
+		 * Resume from stopped, step one instruction.
+		 * We fall through to the UTRACE_REPORT case.
+		 */
+		if (unlikely(!arch_has_single_step())) {
+			WARN_ON(1);
+			reset = false;
+			ret = -EOPNOTSUPP;
+			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.
+		 */
+		clear_engine_wants_stop(engine);
+		if (action < utrace->resume) {
+			utrace->resume = action;
+			set_notify_resume(target);
+		}
+		break;
+
+	case UTRACE_INTERRUPT:
+		/*
+		 * Make the thread call tracehook_get_signal() soon.
+		 */
+		clear_engine_wants_stop(engine);
+		if (utrace->resume == UTRACE_INTERRUPT)
+			break;
+		utrace->resume = UTRACE_INTERRUPT;
+
+		/*
+		 * 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->resume to force it on.
+		 */
+		if (reset) {
+			/*
+			 * 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;
+	}
+
+	/*
+	 * Let the thread resume running.  If it's not stopped now,
+	 * there is nothing more we need to do.
+	 */
+	if (reset)
+		utrace_reset(target, utrace);
+	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 {
+	u32 result;
+	enum utrace_resume_action action;
+	enum utrace_resume_action resume_action;
+	bool detaches;
+	bool spurious;
+};
+
+#define INIT_REPORT(var)			\
+	struct utrace_report var = {		\
+		.action = UTRACE_RESUME,	\
+		.resume_action = UTRACE_RESUME,	\
+		.spurious = true 		\
+	}
+
+/*
+ * We are now making the report, so clear the flag saying we need one.
+ * When there is a new attach, ->pending_attach is set just so we will
+ * know to do splice_attaching() here before the callback loop.
+ */
+static enum utrace_resume_action start_report(struct utrace *utrace)
+{
+	enum utrace_resume_action resume = utrace->resume;
+	if (utrace->pending_attach ||
+	    (resume > UTRACE_INTERRUPT && resume < UTRACE_RESUME)) {
+		spin_lock(&utrace->lock);
+		splice_attaching(utrace);
+		resume = utrace->resume;
+		if (resume > UTRACE_INTERRUPT)
+			utrace->resume = UTRACE_RESUME;
+		spin_unlock(&utrace->lock);
+	}
+	return resume;
+}
+
+static inline void finish_report_reset(struct task_struct *task,
+				       struct utrace *utrace,
+				       struct utrace_report *report)
+{
+	if (unlikely(report->spurious || report->detaches)) {
+		spin_lock(&utrace->lock);
+		if (utrace_reset(task, utrace))
+			report->action = UTRACE_RESUME;
+	}
+}
+
+/*
+ * 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 @will_not_stop is true and 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 task_struct *task, struct utrace *utrace,
+			  struct utrace_report *report, bool will_not_stop)
+{
+	enum utrace_resume_action resume = report->action;
+
+	if (resume == UTRACE_STOP)
+		resume = will_not_stop ? UTRACE_REPORT : UTRACE_RESUME;
+
+	if (resume < utrace->resume) {
+		spin_lock(&utrace->lock);
+		utrace->resume = resume;
+		if (resume == UTRACE_INTERRUPT)
+			set_tsk_thread_flag(task, TIF_SIGPENDING);
+		else
+			set_tsk_thread_flag(task, TIF_NOTIFY_RESUME);
+		spin_unlock(&utrace->lock);
+	}
+
+	finish_report_reset(task, utrace, report);
+}
+
+static inline void finish_callback_report(struct task_struct *task,
+					  struct utrace *utrace,
+					  struct utrace_report *report,
+					  struct utrace_engine *engine,
+					  enum utrace_resume_action action)
+{
+	/*
+	 * 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;
+		return;
+	}
+
+	if (action < report->action)
+		report->action = action;
+
+	if (action != UTRACE_STOP) {
+		if (action < report->resume_action)
+			report->resume_action = action;
+
+		if (engine_wants_stop(engine)) {
+			spin_lock(&utrace->lock);
+			clear_engine_wants_stop(engine);
+			spin_unlock(&utrace->lock);
+		}
+
+		return;
+	}
+
+	if (!engine_wants_stop(engine)) {
+		spin_lock(&utrace->lock);
+		/*
+		 * If utrace_control() came in and detached us
+		 * before we got the lock, we must not stop now.
+		 */
+		if (unlikely(engine->ops == &utrace_detached_ops))
+			report->detaches = true;
+		else
+			mark_engine_wants_stop(task, engine);
+		spin_unlock(&utrace->lock);
+	}
+}
+
+/*
+ * 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 task_struct *task, struct utrace *utrace,
+			    struct utrace_report *report,
+			    struct utrace_engine *engine,
+			    u32 ret)
+{
+	report->result = ret & ~UTRACE_RESUME_MASK;
+	finish_callback_report(task, utrace, report, engine,
+			       utrace_resume_action(ret));
+
+	/*
+	 * 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(task, 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->spurious = false;
+		return ops;
+	}
+
+	utrace->reporting = NULL;
+	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(task, utrace, report, true);		      \
+	} while (0)
+#define REPORT_CALLBACKS(rev, task, utrace, report, event, callback, ...)     \
+	do {								      \
+		struct utrace_engine *engine;				      \
+		const struct utrace_engine_ops *ops;			      \
+		list_for_each_entry##rev(engine, &utrace->attached, entry) {  \
+			ops = start_callback(utrace, report, engine, task,    \
+					     event);			      \
+			if (!ops)					      \
+				continue;				      \
+			finish_callback(task, 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);
+}
+
+static inline u32 do_report_syscall_entry(struct pt_regs *regs,
+					  struct task_struct *task,
+					  struct utrace *utrace,
+					  struct utrace_report *report,
+					  u32 resume_report)
+{
+	start_report(utrace);
+	REPORT_CALLBACKS(_reverse, task, utrace, report,
+			 UTRACE_EVENT(SYSCALL_ENTRY), report_syscall_entry,
+			 resume_report | report->result | report->action,
+			 engine, current, regs);
+	finish_report(task, utrace, report, false);
+
+	if (report->action != UTRACE_STOP)
+		return 0;
+
+	utrace_stop(task, utrace, report->resume_action);
+
+	if (fatal_signal_pending(task)) {
+		/*
+		 * We are continuing despite UTRACE_STOP because of a
+		 * SIGKILL.  Don't let the system call actually proceed.
+		 */
+		report->result = UTRACE_SYSCALL_ABORT;
+	} else if (utrace->resume <= UTRACE_REPORT) {
+		/*
+		 * If we've been asked for another report after our stop,
+		 * go back to report (and maybe stop) again before we run
+		 * the system call.  The second (and later) reports are
+		 * marked with the UTRACE_SYSCALL_RESUMED flag so that
+		 * engines know this is a second report at the same
+		 * entry.  This gives them the chance to examine the
+		 * registers anew after they might have been changed
+		 * while we were stopped.
+		 */
+		report->detaches = false;
+		report->spurious = true;
+		report->action = report->resume_action = UTRACE_RESUME;
+		return UTRACE_SYSCALL_RESUMED;
+	}
+
+	return 0;
+}
+
+/*
+ * 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);
+	u32 resume_report = 0;
+
+	do {
+		resume_report = do_report_syscall_entry(regs, task, utrace,
+							&report, resume_report);
+	} while (resume_report);
+
+	return utrace_syscall_action(report.result) == UTRACE_SYSCALL_ABORT;
+}
+
+/*
+ * 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(task, utrace, &report, !(clone_flags & CLONE_VFORK));
+
+	/*
+	 * 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);
+
+	if (utrace->vfork_stop) {
+		spin_lock(&utrace->lock);
+		utrace->vfork_stop = 0;
+		spin_unlock(&utrace->lock);
+		utrace_stop(task, utrace, UTRACE_RESUME); /* XXX */
+	}
+}
+
+/*
+ * 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);
+
+	spin_unlock_irq(&task->sighand->siglock);
+
+	REPORT(task, utrace, &report, UTRACE_EVENT(JCTL),
+	       report_jctl, what, notify);
+
+	spin_lock_irq(&task->sighand->siglock);
+}
+
+/*
+ * 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, report.resume_action);
+}
+
+/*
+ * 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->resume = UTRACE_RESUME;
+	splice_attaching(utrace);
+	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);
+}
+
+/*
+ * Finish the last reporting pass before returning to user mode.
+ */
+static void finish_resume_report(struct task_struct *task,
+				 struct utrace *utrace,
+				 struct utrace_report *report)
+{
+	finish_report_reset(task, utrace, report);
+
+	switch (report->action) {
+	case UTRACE_STOP:
+		utrace_stop(task, utrace, report->resume_action);
+		break;
+
+	case UTRACE_INTERRUPT:
+		if (!signal_pending(task))
+			set_tsk_thread_flag(task, TIF_SIGPENDING);
+		break;
+
+	case UTRACE_BLOCKSTEP:
+		if (likely(arch_has_block_step())) {
+			user_enable_block_step(task);
+			break;
+		}
+
+		/*
+		 * This means some callback is to blame for failing
+		 * to check arch_has_block_step() itself.  Warn and
+		 * then fall through to treat it as SINGLESTEP.
+		 */
+		WARN_ON(1);
+
+	case UTRACE_SINGLESTEP:
+		if (likely(arch_has_single_step()))
+			user_enable_single_step(task);
+		else
+			/*
+			 * This means some callback is to blame for failing
+			 * to check arch_has_single_step() itself.  Spew
+			 * about it so the loser will fix his module.
+			 */
+			WARN_ON(1);
+		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)) {
+		spin_lock(&utrace->lock);
+		utrace->signal_handler = 0;
+		spin_unlock(&utrace->lock);
+	}
+
+	/*
+	 * Update our bookkeeping even if there are no callbacks made here.
+	 */
+	report.action = start_report(utrace);
+
+	switch (report.action) {
+	case UTRACE_RESUME:
+		/*
+		 * Anything we might have done was already handled by
+		 * utrace_get_signal(), or this is an entirely spurious
+		 * call.  (The arch might use TIF_NOTIFY_RESUME for other
+		 * purposes as well as calling us.)
+		 */
+		return;
+	case UTRACE_REPORT:
+		if (unlikely(!(task->utrace_flags & UTRACE_EVENT(QUIESCE))))
+			break;
+		/*
+		 * Do a simple reporting pass, with no specific
+		 * callback after report_quiesce.
+		 */
+		report.action = UTRACE_RESUME;
+		list_for_each_entry(engine, &utrace->attached, entry)
+			start_callback(utrace, &report, engine, task, 0);
+		break;
+	default:
+		/*
+		 * Even if this report was truly spurious, there is no need
+		 * for utrace_reset() now.  TIF_NOTIFY_RESUME was already
+		 * cleared--it doesn't stay spuriously set.
+		 */
+		report.spurious = false;
+		break;
+	}
+
+	/*
+	 * Finish the report and either stop or get ready to resume.
+	 * If utrace->resume was not UTRACE_REPORT, this applies its
+	 * effect now (i.e. step or interrupt).
+	 */
+	finish_resume_report(task, utrace, &report);
+}
+
+/*
+ * 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)->resume == UTRACE_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_struct(task);
+	if (utrace->resume < UTRACE_RESUME ||
+	    utrace->pending_attach || utrace->signal_handler) {
+		enum utrace_resume_action resume;
+
+		/*
+		 * 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);
+
+		report.result = utrace->signal_handler ?
+			UTRACE_SIGNAL_HANDLER : UTRACE_SIGNAL_REPORT;
+		utrace->signal_handler = 0;
+
+		resume = utrace->resume;
+		utrace->resume = UTRACE_RESUME;
+
+		spin_unlock(&utrace->lock);
+
+		/*
+		 * 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);
+		}
+
+		if (resume > UTRACE_REPORT) {
+			/*
+			 * We only got here to process utrace->resume.
+			 * Despite no callbacks, this report is not spurious.
+			 */
+			report.action = resume;
+			report.spurious = false;
+			finish_resume_report(task, utrace, &report);
+			return -1;
+		} else if (!(task->utrace_flags & UTRACE_EVENT(QUIESCE))) {
+			/*
+			 * 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) ||
+		   unlikely(task->signal->group_stop_count)) {
+		/*
+		 * If no engine is interested in intercepting signals or
+		 * we must stop, let the caller just dequeue them normally
+		 * or participate in group-stop.
+		 */
+		return 0;
+	} else {
+		/*
+		 * 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(task, 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(task, utrace, &report, true);
+
+			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(task, utrace, &report);
+
+		if (unlikely(fatal_signal_pending(task))) {
+			/*
+			 * 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->resume if UTRACE_STOP was used.
+	 */
+	finish_report(task, utrace, &report, true);
+
+	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 (utrace->resume > UTRACE_INTERRUPT) {
+		if (stepping) {
+			utrace->resume = UTRACE_INTERRUPT;
+			set_tsk_thread_flag(task, TIF_SIGPENDING);
+		} else if (utrace->resume == UTRACE_RESUME) {
+			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 be 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)
+{
+	seq_printf(m, "Utrace:\t%lx\n", p->utrace_flags);
+}


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 20:02 [RFC,PATCH 14/14] utrace core Oleg Nesterov
@ 2009-11-24 20:32 ` Andi Kleen
  2009-11-24 20:41   ` Oleg Nesterov
                     ` (2 more replies)
  2009-12-01 19:54 ` Peter Zijlstra
  1 sibling, 3 replies; 37+ messages in thread
From: Andi Kleen @ 2009-11-24 20:32 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo, Molnar <mingo, utrace-devel,
	linux-kernel

Oleg Nesterov <oleg@redhat.com> writes:

> From: Roland McGrath <roland@redhat.com>
>
> 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.

Could we just drop the tracehook layer if this finally merged
and call the low level functions directly?

It might have been reasonably early on when it was still out of tree,
but longer term when it's integrated having strange opaque hooks
like that just makes the coder harder to read and maintain.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 20:32 ` Andi Kleen
@ 2009-11-24 20:41   ` Oleg Nesterov
  2009-11-24 21:26     ` Andi Kleen
  2009-11-25 21:50   ` Christoph Hellwig
  2009-12-01 23:47   ` Roland McGrath
  2 siblings, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-11-24 20:41 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo, Molnar <mingo, utrace-devel,
	linux-kernel

On 11/24, Andi Kleen wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > From: Roland McGrath <roland@redhat.com>
> >
> > 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.
>
> Could we just drop the tracehook layer if this finally merged
> and call the low level functions directly?

Not sure I understand. Tracehooks are trivial inline wrappers on
top utrace calls,

> It might have been reasonably early on when it was still out of tree,
> but longer term when it's integrated having strange opaque hooks
> like that just makes the coder harder to read and maintain.

Well, I don't think the code will be better if we remove tracehooks.

For example. tracehook_report_syscall_entry() has a lot of callers
in arch/, each callsite should be changed to do

	if ((task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_ENTRY)) &&
		utrace_report_syscall_entry(regs))
		ret = -1; // this depends on machine

instead of simply calling tracehook_report_syscall_entry().

What is the point?

But again, perhaps I misunderstood you.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 20:41   ` Oleg Nesterov
@ 2009-11-24 21:26     ` Andi Kleen
  2009-11-24 21:31       ` Frank Ch. Eigler
  2009-11-24 21:44       ` Oleg Nesterov
  0 siblings, 2 replies; 37+ messages in thread
From: Andi Kleen @ 2009-11-24 21:26 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andi Kleen, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo, Molnar <mingo,
	utrace-devel, linux-kernel

On Tue, Nov 24, 2009 at 09:41:52PM +0100, Oleg Nesterov wrote:
> On 11/24, Andi Kleen wrote:
> >
> > Oleg Nesterov <oleg@redhat.com> writes:
> >
> > > From: Roland McGrath <roland@redhat.com>
> > >
> > > 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.
> >
> > Could we just drop the tracehook layer if this finally merged
> > and call the low level functions directly?
> 
> Not sure I understand. Tracehooks are trivial inline wrappers on
> top utrace calls,

Yes that's the problem -- they are unnecessary obfuscation
when you can just call directly.

> 
> > It might have been reasonably early on when it was still out of tree,
> > but longer term when it's integrated having strange opaque hooks
> > like that just makes the coder harder to read and maintain.
> 
> Well, I don't think the code will be better if we remove tracehooks.
> 
> For example. tracehook_report_syscall_entry() has a lot of callers
> in arch/, each callsite should be changed to do
> 
> 	if ((task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_ENTRY)) &&
> 		utrace_report_syscall_entry(regs))
> 		ret = -1; // this depends on machine
> 
> instead of simply calling tracehook_report_syscall_entry().

That should be in the utrace code?

I don't have a problem with having common code somewhere,
just not a whole layer whose only purpose seems to be obfuscation.


> What is the point?

Less code obfuscation.

When it's a utrace call, call it a utrace call, not something else.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 21:26     ` Andi Kleen
@ 2009-11-24 21:31       ` Frank Ch. Eigler
  2009-11-24 21:34         ` Andi Kleen
  2009-11-24 21:44       ` Oleg Nesterov
  1 sibling, 1 reply; 37+ messages in thread
From: Frank Ch. Eigler @ 2009-11-24 21:31 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Oleg Nesterov, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Ingo, Molnar <mingo, utrace-devel,
	linux-kernel

Hi -

On Tue, Nov 24, 2009 at 10:26:19PM +0100, Andi Kleen wrote:
> [...]
> > For example. tracehook_report_syscall_entry() has a lot of callers
> > in arch/, each callsite should be changed to do
> > 
> > 	if ((task_utrace_flags(current) & UTRACE_EVENT(SYSCALL_ENTRY)) &&
> > 		utrace_report_syscall_entry(regs))
> > 		ret = -1; // this depends on machine
> > 
> > instead of simply calling tracehook_report_syscall_entry().
> 
> That should be in the utrace code?
> 
> I don't have a problem with having common code somewhere,
> just not a whole layer whose only purpose seems to be obfuscation.

One man's obfuscation is another man's abstraction.
Would you be satisfied if "tracehook_" was renamed "utracehook_"?


- FChE

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 21:31       ` Frank Ch. Eigler
@ 2009-11-24 21:34         ` Andi Kleen
  0 siblings, 0 replies; 37+ messages in thread
From: Andi Kleen @ 2009-11-24 21:34 UTC (permalink / raw)
  To: Frank Ch. Eigler
  Cc: Andi Kleen, Oleg Nesterov, Alexey Dobriyan,
	Ananth Mavinakayanahalli, Christoph Hellwig, Ingo,
	Molnar <mingo, utrace-devel, linux-kernel

> One man's obfuscation is another man's abstraction.
> Would you be satisfied if "tracehook_" was renamed "utracehook_"?

I would prefer if there were no thin inlines, and the functions should
have a name clearly indicating for which subsystem they are for.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 21:26     ` Andi Kleen
  2009-11-24 21:31       ` Frank Ch. Eigler
@ 2009-11-24 21:44       ` Oleg Nesterov
  2009-11-25  8:46         ` Andi Kleen
  1 sibling, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-11-24 21:44 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Frank Ch. Eigler,
	Ingo Molnar, Peter Zijlstra, Roland McGrath, linux-kernel,
	utrace-devel

(restore cc's)

On 11/24, Andi Kleen wrote:
>
> On Tue, Nov 24, 2009 at 09:41:52PM +0100, Oleg Nesterov wrote:
> > On 11/24, Andi Kleen wrote:
> > >
> > > Oleg Nesterov <oleg@redhat.com> writes:
> > >
> > > > From: Roland McGrath <roland@redhat.com>
> > > >
> > > > 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.
> > >
> > > Could we just drop the tracehook layer if this finally merged
> > > and call the low level functions directly?
> >
> > Not sure I understand. Tracehooks are trivial inline wrappers on
> > top utrace calls,
>
> Yes that's the problem -- they are unnecessary obfuscation
> when you can just call directly.

This is subjective, but personally I disagree. Contrary, imho it
is good that tracehook hides the (simple) details. I do not understand
why the reader of, say, do_fork() should see the contents of
tracehook_report_clone_complete(). This will complicate the understanding.
Those people who want to understand/change fork() do not care about
utrace/ptrace usually.

And please note that it is much, much easier to change this code
when it lives in tracehooks.h instead of sched.c/signal.c/etc.

> > What is the point?
>
> Less code obfuscation.
>
> When it's a utrace call, call it a utrace call, not something else.

Why do you think this is obfuscation? Well, we can rename these
helpers, s/tracehook_/utrace_/, but I don't see how this can make
the code more readable.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 21:44       ` Oleg Nesterov
@ 2009-11-25  8:46         ` Andi Kleen
  2009-11-25 14:55           ` Oleg Nesterov
  0 siblings, 1 reply; 37+ messages in thread
From: Andi Kleen @ 2009-11-25  8:46 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andi Kleen, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Frank Ch. Eigler, Ingo Molnar, Peter Zijlstra, Roland McGrath,
	linux-kernel, utrace-devel

> This is subjective, but personally I disagree. Contrary, imho it
> is good that tracehook hides the (simple) details. I do not understand
> why the reader of, say, do_fork() should see the contents of
> tracehook_report_clone_complete(). This will complicate the understanding.

Someone who has to debug or review fork needs to know what's going on.

Yes they can find out by going through inlines, but that
just costs more time and distracts from the actual problem.

> Those people who want to understand/change fork() do not care about
> utrace/ptrace usually.
> 
> And please note that it is much, much easier to change this code
> when it lives in tracehooks.h instead of sched.c/signal.c/etc.

The problem is that when you have to trace this code when something
goes wrong the extra layer just holds you up. For debugging usually
abstraction is a bad idea.

My experience is also that in general such extra "abstraction layers"
are frowned upon in Linux kernel code style. For example when new
vendor drivers are submitted for hardware like NICs etc,
they frequently tend to have all kinds of "abstraction layers".
Typically the first step to linuxify them is to get rid of those. 

This makes the code more readable, shorter, better to debug and read.

Another classic example is: lock_foo() is frowned upon (Linus
tends to always complain about that), rather prefer spin_lock(&foo_lock)
or mutex_lock(&foo_lock) that makes it clear what's going on.

I don't see why this should be any different for utrace.

> > Less code obfuscation.
> >
> > When it's a utrace call, call it a utrace call, not something else.
> 
> Why do you think this is obfuscation? Well, we can rename these
> helpers, s/tracehook_/utrace_/, but I don't see how this can make
> the code more readable.

Because the inlines do not add anything to functionality and actually
hide what the code does, that is obfuscation. For you it might be obvious
because you've been hacking that code for quite some time, but for 
someone who is not in your position that's different.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-25  8:46         ` Andi Kleen
@ 2009-11-25 14:55           ` Oleg Nesterov
  2009-11-25 16:00             ` Ingo Molnar
  0 siblings, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-11-25 14:55 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Frank Ch. Eigler,
	Ingo Molnar, Peter Zijlstra, Roland McGrath, linux-kernel,
	utrace-devel

On 11/25, Andi Kleen wrote:
>
> > This is subjective, but personally I disagree. Contrary, imho it
> > is good that tracehook hides the (simple) details. I do not understand
> > why the reader of, say, do_fork() should see the contents of
> > tracehook_report_clone_complete(). This will complicate the understanding.
>
> Someone who has to debug or review fork needs to know what's going on.
>
> Yes they can find out by going through inlines, but that
> just costs more time and distracts from the actual problem.
>
> > Those people who want to understand/change fork() do not care about
> > utrace/ptrace usually.
> >
> > And please note that it is much, much easier to change this code
> > when it lives in tracehooks.h instead of sched.c/signal.c/etc.
>
> The problem is that when you have to trace this code when something
> goes wrong the extra layer just holds you up. For debugging usually
> abstraction is a bad idea.
>
> My experience is also that in general such extra "abstraction layers"
> are frowned upon in Linux kernel code style. For example when new
> vendor drivers are submitted for hardware like NICs etc,
> they frequently tend to have all kinds of "abstraction layers".
> Typically the first step to linuxify them is to get rid of those.
>
> This makes the code more readable, shorter, better to debug and read.

OK, let's try to remove these helpers. Let's take a random one,
tracehook_report_exec().

The current code in search_binary_handler:

		if (retval >= 0) {
			if (depth == 0)
				tracehook_report_exec(fmt, bprm, regs);
			put_binfmt(fmt);
			allow_write_access(bprm->file);
			if (bprm->file)
				fput(bprm->file);
			bprm->file = NULL;
			current->did_exec = 1;
			proc_exec_connector(current);
			return retval;
		}

becomes:	

		if (retval >= 0) {
			if (depth == 0) {
				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);
			}
			put_binfmt(fmt);
			allow_write_access(bprm->file);
			if (bprm->file)
				fput(bprm->file);
			bprm->file = NULL;
			current->did_exec = 1;
			proc_exec_connector(current);
			return retval;
		}

Cleanup? I don't think so.

OK, when CONFIG_UTRACE goes away, we can kill a lot of old code, and
in tracehooks too. So the code above becomes

		if (retval >= 0) {
			if (depth == 0) {
				if (unlikely(task_utrace_flags(current) & UTRACE_EVENT(EXEC)))
					utrace_report_exec(fmt, bprm, regs);
			}
			put_binfmt(fmt);
			allow_write_access(bprm->file);
			if (bprm->file)
				fput(bprm->file);
			bprm->file = NULL;
			current->did_exec = 1;
			proc_exec_connector(current);
			return retval;
		}

Much better. But in this case please note that most of tracehooks
just do:

		if (unlikely(task_utrace_flags(current) & SOME_EVENT))
			utrace_report_some_event();

I really don't understand why we shouldn't have (trivial!) helpers
for this. (As for naming - personally I do not care at all ;)

You can argue that some tracehooks (say, exit_notify() path) can be
simplified. Yes, we are going to do this. And again, when CONFIG_UTRACE
goes away, we can just kill some tracehooks. Say, most of them in
do_fork() path.

> Because the inlines do not add anything to functionality and actually
> hide what the code does, that is obfuscation.

This applies to any function. As for tracehooks, they mostly hide
"if (task_utrace_flags(current))" check and nothing more.

> For you it might be obvious
> because you've been hacking that code for quite some time, but for
> someone who is not in your position that's different.

Yes, this is true. Let me repeat, I know that this is subjective and
I am biased.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-25 14:55           ` Oleg Nesterov
@ 2009-11-25 16:00             ` Ingo Molnar
  0 siblings, 0 replies; 37+ messages in thread
From: Ingo Molnar @ 2009-11-25 16:00 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andi Kleen, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Frank Ch. Eigler, Peter Zijlstra, Roland McGrath, linux-kernel,
	utrace-devel


* Oleg Nesterov <oleg@redhat.com> wrote:

> Much better. But in this case please note that most of tracehooks just 
> do:
> 
> 		if (unlikely(task_utrace_flags(current) & SOME_EVENT))
> 			utrace_report_some_event();
> 
> I really don't understand why we shouldn't have (trivial!) helpers for 
> this. (As for naming - personally I do not care at all ;)

We prefer helpers in most such cases - especially when in the normal 
case the helper has no side effects - as here. Then we want to compress 
all such reporting/callback as much as possible.

Using helpers to abstract away functionality is one of the basic 
elements of writing clean kernel code.

	Ingo

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 20:32 ` Andi Kleen
  2009-11-24 20:41   ` Oleg Nesterov
@ 2009-11-25 21:50   ` Christoph Hellwig
  2009-12-01 23:47   ` Roland McGrath
  2 siblings, 0 replies; 37+ messages in thread
From: Christoph Hellwig @ 2009-11-25 21:50 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Oleg Nesterov, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo, Molnar <mingo,
	utrace-devel, linux-kernel

On Tue, Nov 24, 2009 at 09:32:27PM +0100, Andi Kleen wrote:
> Oleg Nesterov <oleg@redhat.com> writes:
> 
> > From: Roland McGrath <roland@redhat.com>
> >
> > 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.
> 
> Could we just drop the tracehook layer if this finally merged
> and call the low level functions directly?
> 
> It might have been reasonably early on when it was still out of tree,
> but longer term when it's integrated having strange opaque hooks
> like that just makes the coder harder to read and maintain.

I agree that linux/tracehook.h as a separate layer is pretty annoying,
but a lot of the helper actually are quite useful.  I'd suggest to throw
a patch ontop of the series to rename all the useful macros to utrace_
and move them into utrace.h and just remove those that are really
trivial wrappers.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 20:02 [RFC,PATCH 14/14] utrace core Oleg Nesterov
  2009-11-24 20:32 ` Andi Kleen
@ 2009-12-01 19:54 ` Peter Zijlstra
  2009-12-01 22:08   ` Oleg Nesterov
                     ` (4 more replies)
  1 sibling, 5 replies; 37+ messages in thread
From: Peter Zijlstra @ 2009-12-01 19:54 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On Tue, 2009-11-24 at 21:02 +0100, Oleg Nesterov wrote:

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

This above text seems inconsistent. First you say report_reap() is the
final callback and should be used for cleanup, then you say
report_death() is the penultimate callback but might not always happen
and people would normally use that as cleanup.

If we cannot rely on report_death() then I would suggest to simply
recommend report_reap() as cleanup callback and leave it at that.

> +  <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>. 

Sure there is, get_task_struct() comes to mind.

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

And here you imply its existence.

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

The above seems weird to me at best... why hold a pid around when you
can keep a ref on the task struct? A pid might get reused leaving you
with a completely different task than you thought you had.

> +  </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>

Right, except you cannot generally rely on this report_death() thing, so
a trace engine needs to deal with the report_reap() thing anyway.

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

Hrmm, better mention this earlier, or at least refer to this when
describing the above cleanup bits.


> +<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. 

'or' 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>


> @@ -351,6 +394,10 @@ static inline void tracehook_report_vfor
>   */
>  static inline void tracehook_prepare_release_task(struct task_struct *task)
>  {
> +	/* see utrace_add_engine() about this barrier */
> +	smp_mb();
> +	if (task_utrace_flags(task))
> +		utrace_release_task(task);
>  }

OK, that seems to properly order ->exit_state vs ->utrace_flags,

This site does:

 assign ->state
 mb
 observe ->utrace_flags

and the other site does:

 assign ->utrace_flags
 mb
 observe ->exit_state
 
> @@ -560,6 +625,20 @@ static inline void tracehook_report_deat
>  					  int signal, void *death_cookie,
>  					  int group_dead)
>  {
> +	/*
> +	 * This barrier ensures that our caller's setting of
> +	 * @task->exit_state precedes checking @task->utrace_flags here.
> +	 * If utrace_set_events() was just called to enable
> +	 * UTRACE_EVENT(DEATH), then we are obliged to call
> +	 * utrace_report_death() and not miss it.  utrace_set_events()
> +	 * uses tasklist_lock to synchronize enabling the bit with the
> +	 * actual change to @task->exit_state, but we need this barrier
> +	 * to be sure we see a flags change made just before our caller
> +	 * took the tasklist_lock.
> +	 */
> +	smp_mb();
> +	if (task_utrace_flags(task) & _UTRACE_DEATH_EVENTS)
> +		utrace_report_death(task, death_cookie, group_dead, signal);
>  }

I don't think its allowed to pair a mb with a lock-barrier, since the
lock barriers are semi-permeable.

> @@ -589,10 +668,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);
>  }

Sending an IPI implies the mb? I seem to remember a discussion on that
subject a while back, maybe add that do
Documentation/memory-barriers.txt

> +/*
> + * 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.
> + */
> +void utrace_free_task(struct task_struct *)
> +	__attribute__((weak));
> +bool utrace_interrupt_pending(void)
> +	__attribute__((weak));
> +void utrace_resume(struct task_struct *, struct pt_regs *)
> +	__attribute__((weak));
> +void utrace_finish_stop(void)
> +	__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));

Can the compiler optimize away the callsite using weak functions like
this? If not I think the normal static inline stubs make more sense.

Also, what unoptimized compilation?

> +static inline struct utrace *task_utrace_struct(struct task_struct *task)
> +{
> +	struct utrace *utrace;
> +
> +	/*
> +	 * This barrier ensures that any prior load of task->utrace_flags
> +	 * is ordered before this load of task->utrace.  We use those
> +	 * utrace_flags checks in the hot path to decide to call into
> +	 * the utrace code.  The first attach installs task->utrace before
> +	 * setting task->utrace_flags nonzero, with a barrier between.
> +	 * See utrace_task_alloc().
> +	 */
> +	smp_rmb();
> +	utrace = task->utrace;
> +
> +	smp_read_barrier_depends(); /* See utrace_task_alloc().  */
> +	return utrace;
> +}

I spot two barriers here, but only 1 over in utrace_task_alloc(), hmm?

> +/*
> + * 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	20090421

I don't think this is desired. Out-of-tree stuff just doesn't exist,
plain pure and simple.

> +enum utrace_resume_action {
> +	UTRACE_STOP,
> +	UTRACE_INTERRUPT,
> +	UTRACE_REPORT,
> +	UTRACE_SINGLESTEP,
> +	UTRACE_BLOCKSTEP,
> +	UTRACE_RESUME,
> +	UTRACE_DETACH
> +};
> +#define	UTRACE_RESUME_MASK	0x07

> +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.  */

> +enum utrace_syscall_action {
> +	UTRACE_SYSCALL_RUN	= 0x00,
> +	UTRACE_SYSCALL_ABORT	= 0x10
> +};
> +#define	UTRACE_SYSCALL_MASK	0xf0
> +#define	UTRACE_SYSCALL_RESUMED	0x100 /* Flag, report_syscall_entry() repeats */

Right, so this lot doesn't seem very consistent.

At the very least I would put signal action and syscall action into
different ranges.

> +/*
> + * 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

My OCD tells me these are ordered wrong :-)

> +/**
> + * 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;
> +	void (*release)(void *);
> +	struct list_head entry;
> +
> +/* public: */
> +	const struct utrace_engine_ops *ops;
> +	void *data;
> +
> +	unsigned long flags;
> +};

Sorry, the kernel is written in C, not C++.

> +/**
> + * 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.

Given that some functions have a lot of arguments (depleting regparam),
isn't it more expensive to push current on the stack than it is to
simply read it again?

> + * 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. 

> + */
> +struct utrace_engine_ops {

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

> +};

Seems inconsistent on u32 vs enum utrace_resume_action.

Why force enum utrace_resume_action into a u32?

> +/**
> + * 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;
> +};

Again, its not C++, if you want a private state like that, use an opaque
type, like:

struct utrace_examiner;

and only define the thing in utrace.c or something.

> +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);
> +}

Is that comment correct? Without rcu_read_lock() the pidhash can change
under our feet and maybe cause funny things?

Same for utrace_*_pid() it seems.

Does pid_task() in generaly rely on havin rcu_read_lock() called? If so,
a change in the implementation could break the assumptions here.

> +/*
> + * Per-thread structure private to utrace implementation.

See, you do know how to do private in C ;-)

> + */
> +struct utrace {
> +	spinlock_t lock;
> +	struct list_head attached, attaching;
> +
> +	struct task_struct *cloning;
> +
> +	struct utrace_engine *reporting;
> +
> +	enum utrace_resume_action resume:3;
> +	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 */
> +	unsigned int pending_attach:1; /* need splice_attaching() */
> +};

Seems inconsistent in the bitfield type, also it feels like that 3 the 7
and the enum should be more tightly integrated, maybe add:

UTRACE_RESUME_MAX

#define UTRACE_RESUME_BITS (ilog2(UTRACE_RESUME_MAX))
#define UTRACE_RESUME_MASK ((1 << UTRACE_RESUME_BITS) - 1)

And pick something consistent: u32, unsigned int or enum
utrace_resume_action.

> +/*
> + * Set up @task.utrace for the first time.  We can have races
> + * between two utrace_attach_task() calls here.  The task_lock()
> + * governs installing the new pointer.  If another one got in first,
> + * we just punt the new one we allocated.
> + *
> + * This returns false only in case of a memory allocation failure.
> + */
> +static bool utrace_task_alloc(struct task_struct *task)
> +{
> +	struct utrace *utrace = kmem_cache_zalloc(utrace_cachep, GFP_KERNEL);
> +	if (unlikely(!utrace))
> +		return false;
> +	spin_lock_init(&utrace->lock);
> +	INIT_LIST_HEAD(&utrace->attached);
> +	INIT_LIST_HEAD(&utrace->attaching);
> +	utrace->resume = UTRACE_RESUME;
> +	task_lock(task);
> +	if (likely(!task->utrace)) {
> +		/*
> +		 * This barrier makes sure the initialization of the struct
> +		 * precedes the installation of the pointer.  This pairs
> +		 * with smp_read_barrier_depends() in task_utrace_struct().
> +		 */
> +		smp_wmb();
> +		task->utrace = utrace;
> +	}
> +	task_unlock(task);
> +	/*
> +	 * That unlock after storing task->utrace acts as a memory barrier
> +	 * ordering any subsequent task->utrace_flags store afterwards.
> +	 * This pairs with smp_rmb() in task_utrace_struct().
> +	 */
> +	if (unlikely(task->utrace != utrace))
> +		kmem_cache_free(utrace_cachep, utrace);
> +	return true;
> +}

Again, not sure we can pair an UNLOCK-barrier with a RMB. In fact, both
are NOPs on x86.

> +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;
> +}

The function does a search, suggesting the function name ought to have
something like find or search in it.

> +/*
> + * 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) &&
> +	    task_utrace_struct(current) &&
> +	    task_utrace_struct(current)->cloning != target)
> +		do {
> +			schedule_timeout_interruptible(1);
> +			if (signal_pending(current))
> +				return -ERESTARTNOINTR;
> +		} while (target->flags & PF_STARTING);
> +
> +	return 0;
> +}

Quite gross this.. can't we key off the
tracehoook_report_clone_complete() and use a wakeup there?

Does this really need the inline?

Also, that if stmt really wants brackets.

> +/*
> + * Called with utrace->lock held and utrace->reap set.
> + * 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;
> +
> +	/* utrace_add_engine() checks ->utrace_flags != 0 */
> +	target->utrace_flags = 0;
> +	splice_attaching(utrace);
> +
> +	/*
> +	 * Since we were called with @utrace->reap set, nobody can
> +	 * set/clear UTRACE_EVENT(REAP) in @engine->flags or change
> +	 * @engine->ops, and nobody can change @utrace->attached.
> +	 */
> +	spin_unlock(&utrace->lock);
> +
> +	list_for_each_entry_safe(engine, next, &utrace->attached, entry) {
> +		if (engine->flags & UTRACE_EVENT(REAP))
> +			engine->ops->report_reap(engine, target);
> +
> +		engine->ops = NULL;
> +		engine->flags = 0;
> +		list_del_init(&engine->entry);
> +
> +		utrace_engine_put(engine);
> +	}
> +}

Asymmetric locking like this is really better not done, and looking at
the callsites its really no bother to clean that up, arguably even makes
them saner.


> +/*
> + * 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);
> +}

It would be more readable to split that comment into two, one part going
near the wmb, and leaving the top part describing the function, not hte
implementation.

The comments in general tend to be too long and verbose, split them up
in to shorter 3-4 line paragraphs with clear subjects/points.

Furthermore I'd add a function like:

static struct utrace_engine_ops *
get_utrace_ops(struct utrace_engine *engine, unsigned long *flags)
{
	*flags = engine->flags;
	/*
	 * 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.
	 */
	smp_rmb();
	return engine->ops;
}

to take out and explicitly comment that common bit.

Also, I'm not quite sure on why we play so many barrier games, looking
at start_callback() we have 2 barriers in the callback loop, why not a
per engine lock?

> +/*
> + * 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)
> +{
> +	if (task_is_stopped(target)) {
> +		/*
> +		 * Stopped is considered quiescent; when it wakes up, it will
> +		 * go through utrace_finish_stop() before doing anything else.
> +		 */
> +		spin_lock_irq(&target->sighand->siglock);
> +		if (likely(task_is_stopped(target)))
> +			__set_task_state(target, TASK_TRACED);
> +		spin_unlock_irq(&target->sighand->siglock);
> +	} else if (utrace->resume > UTRACE_REPORT) {
> +		utrace->resume = UTRACE_REPORT;
> +		set_notify_resume(target);
> +	}
> +
> +	return task_is_traced(target);

You could codify locking assumptions like here using:

  lockdep_assert_held(&utrace->lock);

Saves a comment and actually validates the assumption.


> +/*
> + * 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.  Returns true if we're now fully detached.
> + *
> + * Called with @utrace->lock held, returns with it released.
> + * After this returns, @utrace might be freed if everything detached.
> + */
> +static bool utrace_reset(struct task_struct *task, struct utrace *utrace)
> +	__releases(utrace->lock)
> +{
> +	struct utrace_engine *engine, *next;
> +	unsigned long flags = 0;
> +	LIST_HEAD(detached);
> +
> +	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);
> +		}
> +	}
> +
> +	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);
> +	} else if (!(flags & UTRACE_EVENT_SYSCALL) &&
> +		   test_tsk_thread_flag(task, TIF_SYSCALL_TRACE)) {
> +		clear_tsk_thread_flag(task, TIF_SYSCALL_TRACE);
> +	}
> +
> +	if (!flags) {
> +		/*
> +		 * No more engines, cleared out the utrace.
> +		 */
> +		utrace->resume = UTRACE_RESUME;
> +		utrace->signal_handler = 0;
> +	}
> +
> +	if (task_is_traced(task) && !(flags & ENGINE_STOP))
> +		/*
> +		 * No more engines want it stopped.  Wake it up.
> +		 */
> +		utrace_wakeup(task, utrace);

wants braces.

> +	/*
> +	 * In theory spin_lock() doesn't imply rcu_read_lock().
> +	 * Once we clear ->utrace_flags this task_struct can go away
> +	 * because tracehook_prepare_release_task() path does not take
> +	 * utrace->lock when ->utrace_flags == 0.
> +	 */
> +	rcu_read_lock();
> +	task->utrace_flags = flags;
> +	spin_unlock(&utrace->lock);
> +	rcu_read_unlock();

yuck!

why not simply keep a task reference over the utrace_reset call?

Also, that unlock really wants to be in the caller, things like:

 if (reset)
   utrace_reset()
 else
   spin_unlock(&utrace->lock)

are just vile.

> +	put_detached_list(&detached);
> +
> +	return !flags;
> +}


> +/*
> + * 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 void utrace_stop(struct task_struct *task, struct utrace *utrace,
> +			enum utrace_resume_action action)
> +{
> +relock:
> +	spin_lock(&utrace->lock);
> +
> +	if (action < utrace->resume) {
> +		/*
> +		 * Ensure a reporting pass when we're resumed.
> +		 */
> +		utrace->resume = action;
> +		if (action == UTRACE_INTERRUPT)
> +			set_thread_flag(TIF_SIGPENDING);
> +		else
> +			set_thread_flag(TIF_NOTIFY_RESUME);
> +	}
> +
> +	/*
> +	 * If the ENGINE_STOP bit is clear in utrace_flags, that means
> +	 * utrace_reset() ran after we processed some UTRACE_STOP return
> +	 * values from callbacks to get here.  If all engines have detached
> +	 * or resumed us, we don't stop.  This check doesn't require
> +	 * siglock, but it should follow the interrupt/report bookkeeping
> +	 * steps (this can matter for UTRACE_RESUME but not UTRACE_DETACH).
> +	 */
> +	if (unlikely(!(task->utrace_flags & ENGINE_STOP))) {
> +		utrace_reset(task, utrace);
> +		if (task->utrace_flags & ENGINE_STOP)
> +			goto relock;
> +		return;
> +	}
> +
> +	/*
> +	 * 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_irq(&task->sighand->siglock);
> +
> +	if (unlikely(__fatal_signal_pending(task))) {
> +		spin_unlock_irq(&task->sighand->siglock);
> +		spin_unlock(&utrace->lock);
> +		return;
> +	}
> +
> +	__set_current_state(TASK_TRACED);
> +
> +	/*
> +	 * If there is a group stop in progress,
> +	 * we must participate in the bookkeeping.
> +	 */
> +	if (unlikely(task->signal->group_stop_count) &&
> +			!--task->signal->group_stop_count)
> +		task->signal->flags = SIGNAL_STOP_STOPPED;
> +
> +	spin_unlock_irq(&task->sighand->siglock);
> +	spin_unlock(&utrace->lock);
> +
> +	/*
> +	 * If ptrace is among the reasons for this stop, do its
> +	 * notification now.  This could not just be done in
> +	 * ptrace's own event report callbacks because it has to
> +	 * be done after we are in TASK_TRACED.  This makes the
> +	 * synchronization with ptrace_do_wait() work right.
> +	 */
> +	ptrace_notify_stop(task);

Well, this is a bit disappointing isn't it? So we cannot implement
ptrace on utrace without special purpose hooks?

> +	schedule();
> +
> +	utrace_finish_stop();
> +
> +	/*
> +	 * 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();
> +
> +	/*
> +	 * 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);
> +}



> +/**

> + */
> +int utrace_control(struct task_struct *target,
> +		   struct utrace_engine *engine,
> +		   enum utrace_resume_action action)
> +{
> +	struct utrace *utrace;
> +	bool reset;
> +	int ret;
> +
> +	if (unlikely(action > UTRACE_DETACH))
> +		return -EINVAL;

If you'd have added UTRACE_RESUME_MAX, you could have avoided the
assumption DETACH is the last one.

> +	/*
> +	 * This is a sanity check for a programming error in the caller.
> +	 * Their request can only work properly in all cases by relying on
> +	 * a follow-up callback, but they didn't set one up!  This check
> +	 * doesn't do locking, but it shouldn't matter.  The caller has to
> +	 * be synchronously sure the callback is set up to be operating the
> +	 * interface properly.
> +	 */
> +	if (action >= UTRACE_REPORT && action < UTRACE_RESUME &&
> +	    unlikely(!(engine->flags & UTRACE_EVENT(QUIESCE))))
> +		return -EINVAL;

If its a programming error, WARN_ON might be appropriate, no point in
being nice about it.

> +	utrace = get_utrace_lock(target, engine, true);
> +	if (unlikely(IS_ERR(utrace)))
> +		return PTR_ERR(utrace);
> +
> +	reset = task_is_traced(target);
> +	ret = 0;
> +
> +	/*
> +	 * ->exit_state can change under us, this doesn't matter.
> +	 * We do not care about ->exit_state in fact, but we do
> +	 * care about ->reap and ->death. If either flag is set,
> +	 * we must also see ->exit_state != 0.
> +	 */
> +	if (unlikely(target->exit_state)) {
> +		ret = utrace_control_dead(target, utrace, action);
> +		if (ret) {
> +			spin_unlock(&utrace->lock);
> +			return ret;
> +		}
> +		reset = true;
> +	}
> +
> +	switch (action) {

> +	}
> +
> +	/*
> +	 * Let the thread resume running.  If it's not stopped now,
> +	 * there is nothing more we need to do.
> +	 */
> +	if (reset)
> +		utrace_reset(target, utrace);
> +	else
> +		spin_unlock(&utrace->lock);

yuckness..

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

Seriously ugly, again. Use a wakeup where appropriate.

> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(utrace_barrier);

> +/*
> + * We are now making the report, so clear the flag saying we need one.
> + * When there is a new attach, ->pending_attach is set just so we will
> + * know to do splice_attaching() here before the callback loop.
> + */
> +static enum utrace_resume_action start_report(struct utrace *utrace)
> +{
> +	enum utrace_resume_action resume = utrace->resume;
> +	if (utrace->pending_attach ||
> +	    (resume > UTRACE_INTERRUPT && resume < UTRACE_RESUME)) {
> +		spin_lock(&utrace->lock);
> +		splice_attaching(utrace);
> +		resume = utrace->resume;
> +		if (resume > UTRACE_INTERRUPT)
> +			utrace->resume = UTRACE_RESUME;
> +		spin_unlock(&utrace->lock);
> +	}
> +	return resume;
> +}

Its not entirely clear why we can check pending_attach outside of the
utrace->lock and not be racy.

> +static inline void finish_report_reset(struct task_struct *task,
> +				       struct utrace *utrace,
> +				       struct utrace_report *report)
> +{
> +	if (unlikely(report->spurious || report->detaches)) {
> +		spin_lock(&utrace->lock);
> +		if (utrace_reset(task, utrace))
> +			report->action = UTRACE_RESUME;
> +	}
> +}

More asymmetric locking...


> +static inline void finish_callback_report(struct task_struct *task,
> +					  struct utrace *utrace,
> +					  struct utrace_report *report,
> +					  struct utrace_engine *engine,
> +					  enum utrace_resume_action action)
> +{
> +	/*
> +	 * 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;
> +		return;
> +	}
> +
> +	if (action < report->action)
> +		report->action = action;
> +
> +	if (action != UTRACE_STOP) {
> +		if (action < report->resume_action)
> +			report->resume_action = action;
> +
> +		if (engine_wants_stop(engine)) {
> +			spin_lock(&utrace->lock);
> +			clear_engine_wants_stop(engine);
> +			spin_unlock(&utrace->lock);
> +		}

Reads funny, but I guess it can only race the right way round?

> +		return;
> +	}
> +
> +	if (!engine_wants_stop(engine)) {
> +		spin_lock(&utrace->lock);
> +		/*
> +		 * If utrace_control() came in and detached us
> +		 * before we got the lock, we must not stop now.
> +		 */
> +		if (unlikely(engine->ops == &utrace_detached_ops))
> +			report->detaches = true;
> +		else
> +			mark_engine_wants_stop(task, engine);
> +		spin_unlock(&utrace->lock);
> +	}
> +}

I'm pretty sure that inline isn't really needed.

> +/*
> + * 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 task_struct *task, struct utrace *utrace,
> +			    struct utrace_report *report,
> +			    struct utrace_engine *engine,
> +			    u32 ret)
> +{
> +	report->result = ret & ~UTRACE_RESUME_MASK;
> +	finish_callback_report(task, utrace, report, engine,
> +			       utrace_resume_action(ret));
> +
> +	/*
> +	 * 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();

Simply cond_resched() is sufficient, but that comment sucks, as it
doesn't mention _why_ it is a good place.

It seems to turn out that finish_callback() is always the last thing we
do in the engine iterations in REPORT_CALLBACKS() and
utrace_get_signal().

> +
> +	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(task, 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->spurious = false;
> +		return ops;
> +	}
> +
> +	utrace->reporting = NULL;
> +	return NULL;
> +}

This function makes my head hurt... it would be very nice to see an
obvious version and a set of patches obfuscating it, with numbers
defending the obfuscation.

> +/*
> + * 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(task, utrace, report, true);		      \
> +	} while (0)
> +#define REPORT_CALLBACKS(rev, task, utrace, report, event, callback, ...)     \
> +	do {								      \
> +		struct utrace_engine *engine;				      \
> +		const struct utrace_engine_ops *ops;			      \
> +		list_for_each_entry##rev(engine, &utrace->attached, entry) {  \
> +			ops = start_callback(utrace, report, engine, task,    \
> +					     event);			      \
> +			if (!ops)					      \
> +				continue;				      \
> +			finish_callback(task, utrace, report, engine,	      \
> +					(*ops->callback)(__VA_ARGS__));	      \
> +		}							      \
> +	} while (0)

My OCD makes me tell you that these macros are defined in the wrong
order.

> +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(task, utrace, &report, !(clone_flags & CLONE_VFORK));
> +
> +	/*
> +	 * 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);
> +	}

So much optimization, weird locking, barriers and here you didn't use
atomic bit ops?

> +}
> +
> +/*
> + * 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);
> +
> +	if (utrace->vfork_stop) {
> +		spin_lock(&utrace->lock);
> +		utrace->vfork_stop = 0;
> +		spin_unlock(&utrace->lock);
> +		utrace_stop(task, utrace, UTRACE_RESUME); /* XXX */
> +	}
> +}

I'm sure that XXX means something,... again that vfork_stop stuff can
only race the right way about, right?

> +
> +/*
> + * 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);
> +
> +	spin_unlock_irq(&task->sighand->siglock);
> +
> +	REPORT(task, utrace, &report, UTRACE_EVENT(JCTL),
> +	       report_jctl, what, notify);
> +
> +	spin_lock_irq(&task->sighand->siglock);
> +}

So much documentation, and non of it says that the JCTL (funny name btw)
callback is done holding siglock... tskk.

> +/*
> + * Finish the last reporting pass before returning to user mode.
> + */
> +static void finish_resume_report(struct task_struct *task,
> +				 struct utrace *utrace,
> +				 struct utrace_report *report)
> +{
> +	finish_report_reset(task, utrace, report);
> +
> +	switch (report->action) {
> +	case UTRACE_STOP:
> +		utrace_stop(task, utrace, report->resume_action);
> +		break;
> +
> +	case UTRACE_INTERRUPT:
> +		if (!signal_pending(task))
> +			set_tsk_thread_flag(task, TIF_SIGPENDING);
> +		break;
> +
> +	case UTRACE_BLOCKSTEP:
> +		if (likely(arch_has_block_step())) {
> +			user_enable_block_step(task);
> +			break;
> +		}
> +
> +		/*
> +		 * This means some callback is to blame for failing
> +		 * to check arch_has_block_step() itself.  Warn and
> +		 * then fall through to treat it as SINGLESTEP.
> +		 */
> +		WARN_ON(1);
> +
> +	case UTRACE_SINGLESTEP:
> +		if (likely(arch_has_single_step()))
> +			user_enable_single_step(task);
> +		else
> +			/*
> +			 * This means some callback is to blame for failing
> +			 * to check arch_has_single_step() itself.  Spew
> +			 * about it so the loser will fix his module.
> +			 */
> +			WARN_ON(1);

wants braces

> +		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();

Hrmm, I would much prefer to fix up the calling conventions of
tracehook_notify_resume() than to bury something like this in the guts
of a tracehook user.

> +	/*
> +	 * 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)) {
> +		spin_lock(&utrace->lock);
> +		utrace->signal_handler = 0;
> +		spin_unlock(&utrace->lock);
> +	}

OK, so maybe you get to explain why this works..

> +
> +	/*
> +	 * Update our bookkeeping even if there are no callbacks made here.
> +	 */
> +	report.action = start_report(utrace);
> +
> +	switch (report.action) {
> +	case UTRACE_RESUME:
> +		/*
> +		 * Anything we might have done was already handled by
> +		 * utrace_get_signal(), or this is an entirely spurious
> +		 * call.  (The arch might use TIF_NOTIFY_RESUME for other
> +		 * purposes as well as calling us.)
> +		 */
> +		return;
> +	case UTRACE_REPORT:
> +		if (unlikely(!(task->utrace_flags & UTRACE_EVENT(QUIESCE))))
> +			break;
> +		/*
> +		 * Do a simple reporting pass, with no specific
> +		 * callback after report_quiesce.
> +		 */
> +		report.action = UTRACE_RESUME;
> +		list_for_each_entry(engine, &utrace->attached, entry)
> +			start_callback(utrace, &report, engine, task, 0);
> +		break;
> +	default:
> +		/*
> +		 * Even if this report was truly spurious, there is no need
> +		 * for utrace_reset() now.  TIF_NOTIFY_RESUME was already
> +		 * cleared--it doesn't stay spuriously set.
> +		 */
> +		report.spurious = false;
> +		break;
> +	}
> +
> +	/*
> +	 * Finish the report and either stop or get ready to resume.
> +	 * If utrace->resume was not UTRACE_REPORT, this applies its
> +	 * effect now (i.e. step or interrupt).
> +	 */
> +	finish_resume_report(task, utrace, &report);
> +}


> +/*
> + * 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);
> +}

Yes, exactly what we need, more funky locking.. 

/me gives up..

OK, so what this code needs is some serious restructuring and
de-obfuscation, after that we can maybe get creative and add some of it
back if the performance numbers agree.

But there's too much ugly locking and barriers to be fully sane.

Also the documentation needs more whitespace, its very hard to digest in
its current form.

I'll try and look at the actual state machine later, when my brain has
recovered from this.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-01 19:54 ` Peter Zijlstra
@ 2009-12-01 22:08   ` Oleg Nesterov
  2009-12-07 18:34     ` Peter Zijlstra
  2009-12-02  5:44   ` Roland McGrath
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-01 22:08 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On 12/01, Peter Zijlstra wrote:
>
> On Tue, 2009-11-24 at 21:02 +0100, Oleg Nesterov wrote:
>
> > +  <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>.
>
> Sure there is, get_task_struct() comes to mind.

it is not exported ;)

Peter, I skipped other comments about the documentation, I never read
it myself. Update: I skipped a lot more for today ;)

> > @@ -351,6 +394,10 @@ static inline void tracehook_report_vfor
> >   */
> >  static inline void tracehook_prepare_release_task(struct task_struct *task)
> >  {
> > +	/* see utrace_add_engine() about this barrier */
> > +	smp_mb();
> > +	if (task_utrace_flags(task))
> > +		utrace_release_task(task);
> >  }
>
> OK, that seems to properly order ->exit_state vs ->utrace_flags,
>
> This site does:
>
>  assign ->state
>  mb
>  observe ->utrace_flags
>
> and the other site does:
>
>  assign ->utrace_flags
>  mb
>  observe ->exit_state

Yes, we hope.

> > @@ -560,6 +625,20 @@ static inline void tracehook_report_deat
> >  					  int signal, void *death_cookie,
> >  					  int group_dead)
> >  {
> > +	/*
> > +	 * This barrier ensures that our caller's setting of
> > +	 * @task->exit_state precedes checking @task->utrace_flags here.
> > +	 * If utrace_set_events() was just called to enable
> > +	 * UTRACE_EVENT(DEATH), then we are obliged to call
> > +	 * utrace_report_death() and not miss it.  utrace_set_events()
> > +	 * uses tasklist_lock to synchronize enabling the bit with the
> > +	 * actual change to @task->exit_state, but we need this barrier
> > +	 * to be sure we see a flags change made just before our caller
> > +	 * took the tasklist_lock.
> > +	 */
> > +	smp_mb();
> > +	if (task_utrace_flags(task) & _UTRACE_DEATH_EVENTS)
> > +		utrace_report_death(task, death_cookie, group_dead, signal);
> >  }
>
> I don't think its allowed to pair a mb with a lock-barrier, since the
> lock barriers are semi-permeable.

Could you clarify?

> > @@ -589,10 +668,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);
> >  }
>
> Sending an IPI implies the mb?

Yes, but this has nothing to do with IPI. The caller, do_notify_resume(),
does:
	clear_thread_flag(TIF_NOTIFY_RESUME);
	tracehook_notify_resume:
		if (task_utrace_flags(task))
			utrace_resume();

We should not read task_utrace_flags() before we clear TIF_NOTIFY_RESUME.

> > +static inline struct utrace *task_utrace_struct(struct task_struct *task)
> > +{
> > +	struct utrace *utrace;
> > +
> > +	/*
> > +	 * This barrier ensures that any prior load of task->utrace_flags
> > +	 * is ordered before this load of task->utrace.  We use those
> > +	 * utrace_flags checks in the hot path to decide to call into
> > +	 * the utrace code.  The first attach installs task->utrace before
> > +	 * setting task->utrace_flags nonzero, with a barrier between.
> > +	 * See utrace_task_alloc().
> > +	 */
> > +	smp_rmb();
> > +	utrace = task->utrace;
> > +
> > +	smp_read_barrier_depends(); /* See utrace_task_alloc().  */
> > +	return utrace;
> > +}
>
> I spot two barriers here, but only 1 over in utrace_task_alloc(), hmm?

smp_read_barrier_depends() pairs with utrace_task_alloc()->wmb().

smp_rmb() is needed for another reason. Suppose the code does:

	if (task_utrace_flags() & SOMETHING)
		do_something_with(task->utrace);

if we race with utrace_attach_task(), we can see ->utrace_flags != 0
but task->utrace == NULL without rmb().

> > +struct utrace_engine {
> > +/* private: */
> > +	struct kref kref;
> > +	void (*release)(void *);
> > +	struct list_head entry;
> > +
> > +/* public: */
> > +	const struct utrace_engine_ops *ops;
> > +	void *data;
> > +
> > +	unsigned long flags;
> > +};
>
> Sorry, the kernel is written in C, not C++.

Hmm. I almost never read the comments, but these 2 look very clear
to me ;)

> > + * 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.
>
> Given that some functions have a lot of arguments (depleting regparam),
> isn't it more expensive to push current on the stack than it is to
> simply read it again?

Yes, perhaps. Only ->report_reap() really needs @task, it may be
!current.

> > +struct utrace_engine_ops {
>
> > +	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);
>
> > +};
>
> Seems inconsistent on u32 vs enum utrace_resume_action.

Well, this u32 can hold utrace_resume_action | utrace_signal_action,
for example.

> > +struct utrace_examiner {
> > +/* private: */
> > +	long state;
> > +	unsigned long ncsw;
> > +};
>
> Again, its not C++, if you want a private state like that, use an opaque
> type, like:
>
> struct utrace_examiner;
>
> and only define the thing in utrace.c or something.

Then the caller of utrace_prepare_examine() has to alloc utrace_examiner
somehow. I disagree here. But of course we can remove this comment.

> > +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);
> > +}
>
> Is that comment correct? Without rcu_read_lock() the pidhash can change
> under our feet and maybe cause funny things?

If pid itself can't go away, it is always safe to use pid_task(). Yes,
we can't trust the returned value, that is why utrace_control() verifies
this task_struct* is still valid.

> Does pid_task() in generaly rely on havin rcu_read_lock() called?

See above. pid_task() itself doesn't need rcu_read_lock(), but without
rcu lock around you can't simply use the result.

> > +static bool utrace_task_alloc(struct task_struct *task)
> > +{
> > +	struct utrace *utrace = kmem_cache_zalloc(utrace_cachep, GFP_KERNEL);
> > +	if (unlikely(!utrace))
> > +		return false;
> > +	spin_lock_init(&utrace->lock);
> > +	INIT_LIST_HEAD(&utrace->attached);
> > +	INIT_LIST_HEAD(&utrace->attaching);
> > +	utrace->resume = UTRACE_RESUME;
> > +	task_lock(task);
> > +	if (likely(!task->utrace)) {
> > +		/*
> > +		 * This barrier makes sure the initialization of the struct
> > +		 * precedes the installation of the pointer.  This pairs
> > +		 * with smp_read_barrier_depends() in task_utrace_struct().
> > +		 */
> > +		smp_wmb();
> > +		task->utrace = utrace;
> > +	}
> > +	task_unlock(task);
> > +	/*
> > +	 * That unlock after storing task->utrace acts as a memory barrier
> > +	 * ordering any subsequent task->utrace_flags store afterwards.
> > +	 * This pairs with smp_rmb() in task_utrace_struct().
> > +	 */
> > +	if (unlikely(task->utrace != utrace))
> > +		kmem_cache_free(utrace_cachep, utrace);
> > +	return true;
> > +}
>
> Again, not sure we can pair an UNLOCK-barrier with a RMB. In fact, both
> are NOPs on x86.

We can't. I think the comment is confusing. We need the barrier
between setting "task->utrace = utrace" and changing ->utrace_flags.
We have unlock+lock in between, this implies mb().

> > +static inline int utrace_attach_delay(struct task_struct *target)
> > +{
> > +	if ((target->flags & PF_STARTING) &&
> > +	    task_utrace_struct(current) &&
> > +	    task_utrace_struct(current)->cloning != target)
> > +		do {
> > +			schedule_timeout_interruptible(1);
> > +			if (signal_pending(current))
> > +				return -ERESTARTNOINTR;
> > +		} while (target->flags & PF_STARTING);
> > +
> > +	return 0;
> > +}
>
> Quite gross this.. can't we key off the
> tracehoook_report_clone_complete() and use a wakeup there?

Yes, it would be very nice to avoid this schedule_timeout_interruptible().
But currently we don't see a simple solution, on the TODO list. But, to
clarify, this case is very unlikely.

> Furthermore I'd add a function like:
>
> static struct utrace_engine_ops *
> get_utrace_ops(struct utrace_engine *engine, unsigned long *flags)
> {
> 	*flags = engine->flags;
> 	/*
> 	 * 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.
> 	 */
> 	smp_rmb();
> 	return engine->ops;
> }
>
> to take out and explicitly comment that common bit.
>
> Also, I'm not quite sure on why we play so many barrier games, looking
> at start_callback() we have 2 barriers in the callback loop, why not a
> per engine lock?

Exactly to avoid the lock, I guess ;)

> > +	/*
> > +	 * In theory spin_lock() doesn't imply rcu_read_lock().
> > +	 * Once we clear ->utrace_flags this task_struct can go away
> > +	 * because tracehook_prepare_release_task() path does not take
> > +	 * utrace->lock when ->utrace_flags == 0.
> > +	 */
> > +	rcu_read_lock();
> > +	task->utrace_flags = flags;
> > +	spin_unlock(&utrace->lock);
> > +	rcu_read_unlock();
>
> yuck!
>
> why not simply keep a task reference over the utrace_reset call?

Yes, we could use get_task_struct() instead. Not sure this would
be more clean, though.

> > +static void utrace_stop(struct task_struct *task, struct utrace *utrace,
> > +			enum utrace_resume_action action)
> > ...
> > +	/*
> > +	 * If ptrace is among the reasons for this stop, do its
> > +	 * notification now.  This could not just be done in
> > +	 * ptrace's own event report callbacks because it has to
> > +	 * be done after we are in TASK_TRACED.  This makes the
> > +	 * synchronization with ptrace_do_wait() work right.
> > +	 */
> > +	ptrace_notify_stop(task);
>
> Well, this is a bit disappointing isn't it? So we cannot implement
> ptrace on utrace without special purpose hooks?

Yes, currently we need the special hook for ptrace. Because ptrace
is really special, no other engine should cooperate with do_wait/etc.

That said, I agree. We need something more general which could be
used by other engines too.

> > +static enum utrace_resume_action start_report(struct utrace *utrace)
> > +{
> > +	enum utrace_resume_action resume = utrace->resume;
> > +	if (utrace->pending_attach ||
> > +	    (resume > UTRACE_INTERRUPT && resume < UTRACE_RESUME)) {
> > +		spin_lock(&utrace->lock);
> > +		splice_attaching(utrace);
> > +		resume = utrace->resume;
> > +		if (resume > UTRACE_INTERRUPT)
> > +			utrace->resume = UTRACE_RESUME;
> > +		spin_unlock(&utrace->lock);
> > +	}
> > +	return resume;
> > +}
>
> Its not entirely clear why we can check pending_attach outside of the
> utrace->lock and not be racy.

We can safely miss utrace->pending_attach here, or even read the "stale"
utrace->resume. Both can be changed after start_report().

> > +static inline void finish_callback_report(struct task_struct *task,
> > +					  struct utrace *utrace,
> > +					  struct utrace_report *report,
> > +					  struct utrace_engine *engine,
> > +					  enum utrace_resume_action action)
> > +{
> > +	/*
> > +	 * 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;
> > +		return;
> > +	}
> > +
> > +	if (action < report->action)
> > +		report->action = action;
> > +
> > +	if (action != UTRACE_STOP) {
> > +		if (action < report->resume_action)
> > +			report->resume_action = action;
> > +
> > +		if (engine_wants_stop(engine)) {
> > +			spin_lock(&utrace->lock);
> > +			clear_engine_wants_stop(engine);
> > +			spin_unlock(&utrace->lock);
> > +		}
>
> Reads funny, but I guess it can only race the right way round?

Not sure I understand... could you explain?

> > +	/*
> > +	 * This is a good place to make sure tracing engines don't
> > +	 * introduce too much latency under voluntary preemption.
> > +	 */
> > +	if (need_resched())
> > +		cond_resched();
>
> Simply cond_resched() is sufficient, but that comment sucks, as it
> doesn't mention _why_ it is a good place.

Hmm, I agree.

> > +	/*
> > +	 * 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);
> > +	}
>
> So much optimization, weird locking, barriers and here you didn't use
> atomic bit ops?

The point is, the state of the tracee must be "stable" under utrace->lock.
As for ->vfork_stop in particular, it should die (imho) but we need further
cleanups outside of utrace.c.

> > +void utrace_finish_vfork(struct task_struct *task)
> > +{
> > +	struct utrace *utrace = task_utrace_struct(task);
> > +
> > +	if (utrace->vfork_stop) {
> > +		spin_lock(&utrace->lock);
> > +		utrace->vfork_stop = 0;
> > +		spin_unlock(&utrace->lock);
> > +		utrace_stop(task, utrace, UTRACE_RESUME); /* XXX */
> > +	}
> > +}
>
> I'm sure that XXX means something,... again that vfork_stop stuff can
> only race the right way about, right?

UTRACE_RESUME is not exactly right, we have the pending patches but
need more discussion.

> > +void utrace_report_jctl(int notify, int what)
> > +{
> > +	struct task_struct *task = current;
> > +	struct utrace *utrace = task_utrace_struct(task);
> > +	INIT_REPORT(report);
> > +
> > +	spin_unlock_irq(&task->sighand->siglock);
> > +
> > +	REPORT(task, utrace, &report, UTRACE_EVENT(JCTL),
> > +	       report_jctl, what, notify);
> > +
> > +	spin_lock_irq(&task->sighand->siglock);
> > +}
>
> So much documentation, and non of it says that the JCTL (funny name btw)
> callback is done holding siglock... tskk.

Not sure I understand, but we unlock ->siglock before REPORT(). If you mean
that utrace_report_jctl() is called under ->siglock, then yes.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-11-24 20:32 ` Andi Kleen
  2009-11-24 20:41   ` Oleg Nesterov
  2009-11-25 21:50   ` Christoph Hellwig
@ 2009-12-01 23:47   ` Roland McGrath
  2 siblings, 0 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-01 23:47 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Oleg Nesterov, Ingo Molnar, linux-kernel, Christoph Hellwig,
	Frank Ch. Eigler, utrace-devel, Alexey Dobriyan

> Could we just drop the tracehook layer if this finally merged
> and call the low level functions directly?

We can certainly do appropriate streamlining cleanups later, by all
means.  The original purpose of the tracehook layer is simply this:

A person hacking on core kernel code or arch code should not have to
think about all the innards of tracing (ptrace, utrace, or anything
else).  If he comes across a tracehook_* call, he can just read its
kernel-doc for explanation of its parameters, return value, what it
expects about its context (locking et al), and what the semantic
significance of making that particular call is.  If changes to the
core/arch code in question do not require changing any of those
aspects, then said person need not consider tracing issues further.
If a change to a function's calling interface or contextual
assumptions looks warranted, then he knows he should discuss the
details with some tracing-related folks (i.e. find tracehook.h in
MAINTAINERS and thus get to me and Oleg).

Likewise, a person hacking on tracing code should not have to think
about every corner of interaction with the core code or arch code.
Each tracehook_* call's kernel-doc comments say everything that
matters about how and where it's called.  If some of those details
are problematic for what we want to do inside the tracing code, then
we know we have to hash out the details with the maintainers of the
core or arch code that makes those calls.  Otherwise we can keep our
focus on tracing infrastructure without spending time getting lost
in arcane details of the arch or core kernel code.

These two things seem permanently worthwhile to me: that the core
and arch source code use simple function calls without open-coding
any innards of the tracing infrastructure; and that these functions
have clear and complete documentation about their calling interfaces
and context (locking et al).  I find it natural and convenient that
such calls have a common prefix that makes it obvious to any reader
of the core code what subsystem the call relates to.

Beyond those ideas, I certainly don't care at all what the names of
these functions are, what common prefix is used, or in which source
files those declarations and kernel-doc comments appear.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-01 19:54 ` Peter Zijlstra
  2009-12-01 22:08   ` Oleg Nesterov
@ 2009-12-02  5:44   ` Roland McGrath
  2009-12-02 18:34   ` Oleg Nesterov
                     ` (2 subsequent siblings)
  4 siblings, 0 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-02  5:44 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Oleg Nesterov, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

> This above text seems inconsistent. First you say report_reap() is the
> final callback and should be used for cleanup, then you say
> report_death() is the penultimate callback but might not always happen
> and people would normally use that as cleanup.
>
> If we cannot rely on report_death() then I would suggest to simply
> recommend report_reap() as cleanup callback and leave it at that.

I'm sorry the explanation was not clear to you.  I'll try to make it clear
now and then I'd appreciate your suggestions on how the documentation could
be worded better.  (I do appreciate your suggestion here but it's one based
on an idea that's not factual, so I don't think we should follow it.)

There is no "unreliable" aspect to it.  If you call utrace_set_events() to
ask for report_death() callbacks then you will get that callback for that
task--guaranteed--unless utrace_set_events() returned an error code that
tells you unambiguously that you could not get that callback.

What's true is that report_reap() is the last callback you can ever
get for a given task.  If you had asked for report_death() callbacks,
then you always get report_death() and if you've asked for both these
callbacks then report_death() is always before report_reap().  
(This is a special ordering guarantee, because in actuality the
release_task() call that constitutes "reap" can happen in the parent
simultaneously with the task's own exit path.)

The one situation in which you cannot get report_death() is when the task
was already dead when you called utrace_set_events().  In that case, it
gives an error code as I mentioned above.  Even in that situation, you can
still ask to enable just the report_reap() callback.  With either of these,
if you enabled it successfully, then you are guaranteed to get it.

When you get report_death() and are not interested in getting report_reap()
afterwards, then you can return UTRACE_DETACH from report_death().  If you
don't detach, then you will get report_reap() later too.  The documentation
mentions using report_death() to detach and clean up because many kinds of
uses will have no interest in report_reap() at all.  The only reason to get
a report_reap() callback is if you are interested in tracking when a task's
(real) parent reaps it with wait* calls, but usually people are only really
interested in a task until it dies.

> > +  <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>. 
> 
> Sure there is, get_task_struct() comes to mind.

__put_task_struct() is not exported to modules and so put_task_struct()
cannot be used by modules.

> > +    still valid until <function>rcu_read_unlock</function>.  The
> > +    infrastructure never holds task references of its own.  
> 
> And here you imply its existence.

[I take it this refers to the next quoted bit:]

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

No, we do not imply that the utrace infrastructure holds any task
reference.  The current task_struct is always live while it's running
and until it's passed to release_task().  The task_struct passed to
callbacks is current.  That's all it means.  

The true facts are that utrace callbacks are all made in the current task
except for report_reap(), which is made at the start of release_task().
So the kernel's core logic is holding a task reference at all times that
utrace callbacks are made.  If you really think it is clearer to explain
that set of facts as "utrace holds a reference", then please suggest the
exact wording you have in mind.

> The above seems weird to me at best... why hold a pid around when you
> can keep a ref on the task struct? A pid might get reused leaving you
> with a completely different task than you thought you had.

The *_pid interfaces are only there because put_pid() can be used by
modules while put_task_struct() cannot.  If we can make __put_task_struct()
an exported symbol again, I would see no reason for these *_pid calls.

> Right, except you cannot generally rely on this report_death() thing, so
> a trace engine needs to deal with the report_reap() thing anyway.

This is a false antecedent.  I hope the explanation above made this
subject clear to you.

> > +  <sect2 id="interlock"><title>Interlock with final callbacks</title>
[...]
> Hrmm, better mention this earlier, or at least refer to this when
> describing the above cleanup bits.

This explanation is somewhat long and has its own whole section so as to
be thoroughly explicit and clear.  Do you think there should just be a
cross reference here in the earlier mention of report_reap() and
report_death()?  Or do you think that the "Final callbacks" text should
be merged together with the "Interlock" section?

> > +  an error if the task is not properly stopped and not dead. 
> 
> 'or' dead?

Yes, fixed.  Thanks!


I've relied on Oleg to review and fix the barrier-related logic.
So I'll leave it to him to hash out those parts of the review.

> Can the compiler optimize away the callsite using weak functions like
> this? If not I think the normal static inline stubs make more sense.

I'm not sure I understand the question.  If the !CONFIG_UTRACE case, this
all boils down to "if (0) utrace_foo(...);" calls after constant folding.
I think the compiler will always compile those out, but I'm not entirely
sure about all old compilers or about -O0.

> Also, what unoptimized compilation?

If there really is none then I guess there isn't a problem.  We can just
drop these weak attributes and the dead calls will be optimized away
before link time anyway.  If we are not positive that is going to fly
everywhere, then I have no objection to adding static inline stubs in the
#else branch if you think that is preferable.

> Right, so this lot doesn't seem very consistent.

Please explain what kind of consistency you have in mind.
I don't follow.

> At the very least I would put signal action and syscall action into
> different ranges.

Those two can never be used in the same place.  So I don't really
understand that.  It doesn't matter what their values are, so I don't
have a problem with changing them to be disjoint.  But I don't understand
why it would be better in any way at all.

> Sorry, the kernel is written in C, not C++.

We know that perfectly well, and I haven't been able ascertain what
benefit you gain by being snide.  Our code follows the instructions in
Documentation/kernel-doc-nano-HOWTO.txt, so if you have a complaint with
that established practice recommened for the kernel please take it up
with the appropriate maintainers.  We're following what the kernel's own
documentation tells us to do.

If you use /** for a struct and omit @field for some fields, then you get
warnings from make *docs.  If you omit all the fields (because none are
part of the documented API, such as in struct utrace_examiner), then you
get a build error.  So unless kernel-doc changes, the options are to
follow its specified /* private: */ convention as we do now, to add a
bunch of "@field: this is an internal field, do not touch it" comments,
or to punt on kernel-doc for these structs.  Which do you want?

> Again, its not C++, if you want a private state like that, use an opaque
> type, like:
> 
> struct utrace_examiner;
> 
> and only define the thing in utrace.c or something.

Again, we are following the kernel-doc instructions for this situation.
If you look at the uses of this type in the interface, you'll see that
its purpose is to have the caller allocate the space.  The only way to
make it opaque would be to use a pointer type and do dynamic allocation
inside some utrace.c function.  That would be inane for holding two words
needed momentarily during one caller's frame.

> Given that some functions have a lot of arguments (depleting regparam),
> isn't it more expensive to push current on the stack than it is to
> simply read it again?

Perhaps so.  The only callback where the task argument is not current is
report_reap().  That one already differs from the calling pattern of all
the others because it has no return value.  So I guess we could drop the
task argument to all the "normal" report_* calls.


I'll pick up with responding to the rest of your remarks as soon as I
can.  (Right now I have to prepare for an airplane early in the morning.)


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-01 19:54 ` Peter Zijlstra
  2009-12-01 22:08   ` Oleg Nesterov
  2009-12-02  5:44   ` Roland McGrath
@ 2009-12-02 18:34   ` Oleg Nesterov
  2009-12-02 18:49   ` Oleg Nesterov
  2009-12-14  0:25   ` Roland McGrath
  4 siblings, 0 replies; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-02 18:34 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On 12/01, Peter Zijlstra wrote:
>
> > +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);
> > +}
>
> Is that comment correct? Without rcu_read_lock() the pidhash can change
> under our feet and maybe cause funny things?

I already tried to answer, but I guess my email was not very clear. Let me
try again.

pid_task() by itself is safe, but yes, it is possible that utrace_control()
is called with target == NULL, or this task_task was already freed/reused.

utrace_control(target) path does not use target until it verifies it is
safe to dereference it.

get_utrace_lock() calls rcu_read_lock() and checks that engine->ops
is not cleared (NULL or utrace_detached_ops). If we see the valid ->ops
under rcu_read_lock() it is safe to dereference target, even if we race
with release_task() we know that it has not passed utrace_release_task()
yet, and thus we know call_rcu(delayed_put_task_struct) was not yet
called _before_ we took rcu_read_lock().

If it is safe to dereference target, we can take utrace->lock. Once
we take this lock (and re-check engine->ops) the task can't go away
until we drop it, get_utrace_lock() drops rcu lock and returns with
utrace->lock held.

utrace_control() can safely play with target under utrace->lock.

> > +	/*
> > +	 * 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)) {
> > +		spin_lock(&utrace->lock);
> > +		utrace->signal_handler = 0;
> > +		spin_unlock(&utrace->lock);
> > +	}
>
> OK, so maybe you get to explain why this works..

Missed this part yesterday.

Well. ->signal_handler is set by handle_signal() when the signal was
delivered to the tracee. This flag is checked by utrace_get_signal()
to detect the stepping. But we should not return to user-mode with
this flag set, that is why utrace_resume() clears it.

However. This reminds me we were going to try to simplify this logic,
I'll try to think about this.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-01 19:54 ` Peter Zijlstra
                     ` (2 preceding siblings ...)
  2009-12-02 18:34   ` Oleg Nesterov
@ 2009-12-02 18:49   ` Oleg Nesterov
  2009-12-05 19:14     ` Roland McGrath
  2009-12-14  0:25   ` Roland McGrath
  4 siblings, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-02 18:49 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On 12/01, Peter Zijlstra wrote:
>
> > +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();
>
> Hrmm, I would much prefer to fix up the calling conventions of
> tracehook_notify_resume() than to bury something like this in the guts
> of a tracehook user.

Missed this part too.

May be, I dunno...

But in any case, imho it would be better to do this after we merge utrace,
otherwise we need more subtle arch-dependent changes before.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-02 18:49   ` Oleg Nesterov
@ 2009-12-05 19:14     ` Roland McGrath
  0 siblings, 0 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-05 19:14 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Peter Zijlstra, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

> > > +	 * 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();
> >
> > Hrmm, I would much prefer to fix up the calling conventions of
> > tracehook_notify_resume() than to bury something like this in the guts
> > of a tracehook user.

The reason I did it this way was mainly just not to make the requirement
for arch maintainers' too subtle.  As it is, we just say that you call
tracehook_notify_resume() after clearing TIF_NOTIFY_RESUME, when it was
set.  That keeps the specification quite simple.  Of course, that is not
really much of a reason.  If arch folks don't mind the requirement to
replace e.g.:

	if (thread_info_flags & _TIF_NOTIFY_RESUME) {
		clear_thread_flag(TIF_NOTIFY_RESUME);
		tracehook_notify_resume(regs);
	}

with:


	if (thread_info_flags & _TIF_NOTIFY_RESUME) {
		local_irq_enable();
		clear_thread_flag(TIF_NOTIFY_RESUME);
		tracehook_notify_resume(regs);
	}

then that is certainly fine by me.  But we do now have almost all the
arch's calling tracehook_notify_resume() and I don't know how many of
them do it in irqs-disabled context so they would need this change.

> But in any case, imho it would be better to do this after we merge utrace,
> otherwise we need more subtle arch-dependent changes before.

I tend to agree.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-01 22:08   ` Oleg Nesterov
@ 2009-12-07 18:34     ` Peter Zijlstra
  2009-12-08 15:04       ` Oleg Nesterov
  0 siblings, 1 reply; 37+ messages in thread
From: Peter Zijlstra @ 2009-12-07 18:34 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On Tue, 2009-12-01 at 23:08 +0100, Oleg Nesterov wrote:

> > > @@ -560,6 +625,20 @@ static inline void tracehook_report_deat
> > >  					  int signal, void *death_cookie,
> > >  					  int group_dead)
> > >  {
> > > +	/*
> > > +	 * This barrier ensures that our caller's setting of
> > > +	 * @task->exit_state precedes checking @task->utrace_flags here.
> > > +	 * If utrace_set_events() was just called to enable
> > > +	 * UTRACE_EVENT(DEATH), then we are obliged to call
> > > +	 * utrace_report_death() and not miss it.  utrace_set_events()
> > > +	 * uses tasklist_lock to synchronize enabling the bit with the
> > > +	 * actual change to @task->exit_state, but we need this barrier
> > > +	 * to be sure we see a flags change made just before our caller
> > > +	 * took the tasklist_lock.
> > > +	 */
> > > +	smp_mb();
> > > +	if (task_utrace_flags(task) & _UTRACE_DEATH_EVENTS)
> > > +		utrace_report_death(task, death_cookie, group_dead, signal);
> > >  }
> >
> > I don't think its allowed to pair a mb with a lock-barrier, since the
> > lock barriers are semi-permeable.
> 
> Could you clarify?

According to memory-barriers.txt a mb can be paired with mb,wmb,rmb
depending on the situation.

For LOCK it states:

(1) LOCK operation implication:

     Memory operations issued after the LOCK will be completed after the LOCK
     operation has completed.

     Memory operations issued before the LOCK may be completed after the LOCK
     operation has completed.

Which is not something I can see making sense to pair with an mb.

So either the comment is confusing and its again referring to an UNLOCK
+LOCK pair, or there's something fishy

> > > @@ -589,10 +668,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);
> > >  }
> >
> > Sending an IPI implies the mb?
> 
> Yes, but this has nothing to do with IPI. The caller, do_notify_resume(),
> does:
> 	clear_thread_flag(TIF_NOTIFY_RESUME);
> 	tracehook_notify_resume:
> 		if (task_utrace_flags(task))
> 			utrace_resume();
> 
> We should not read task_utrace_flags() before we clear TIF_NOTIFY_RESUME.

Then this comment needs an update.. that wasn't at all clear to me.

> > > +static inline struct utrace *task_utrace_struct(struct task_struct *task)
> > > +{
> > > +	struct utrace *utrace;
> > > +
> > > +	/*
> > > +	 * This barrier ensures that any prior load of task->utrace_flags
> > > +	 * is ordered before this load of task->utrace.  We use those
> > > +	 * utrace_flags checks in the hot path to decide to call into
> > > +	 * the utrace code.  The first attach installs task->utrace before
> > > +	 * setting task->utrace_flags nonzero, with a barrier between.
> > > +	 * See utrace_task_alloc().
> > > +	 */
> > > +	smp_rmb();
> > > +	utrace = task->utrace;
> > > +
> > > +	smp_read_barrier_depends(); /* See utrace_task_alloc().  */
> > > +	return utrace;
> > > +}
> >
> > I spot two barriers here, but only 1 over in utrace_task_alloc(), hmm?
> 
> smp_read_barrier_depends() pairs with utrace_task_alloc()->wmb().
> 
> smp_rmb() is needed for another reason. Suppose the code does:
> 
> 	if (task_utrace_flags() & SOMETHING)
> 		do_something_with(task->utrace);
> 
> if we race with utrace_attach_task(), we can see ->utrace_flags != 0
> but task->utrace == NULL without rmb().

Still not clear what we pair with.. There is no obvious barrier in
utrace_attach_task() nor a comment referring to this site.

> > > +struct utrace_engine {
> > > +/* private: */
> > > +	struct kref kref;
> > > +	void (*release)(void *);
> > > +	struct list_head entry;
> > > +
> > > +/* public: */
> > > +	const struct utrace_engine_ops *ops;
> > > +	void *data;
> > > +
> > > +	unsigned long flags;
> > > +};
> >
> > Sorry, the kernel is written in C, not C++.
> 
> Hmm. I almost never read the comments, but these 2 look very clear
> to me ;)

I see no point in adding comments like that at all.

> > > + * 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.
> >
> > Given that some functions have a lot of arguments (depleting regparam),
> > isn't it more expensive to push current on the stack than it is to
> > simply read it again?
> 
> Yes, perhaps. Only ->report_reap() really needs @task, it may be
> !current.
> 
> > > +struct utrace_engine_ops {
> >
> > > +	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);
> >
> > > +};
> >
> > Seems inconsistent on u32 vs enum utrace_resume_action.
> 
> Well, this u32 can hold utrace_resume_action | utrace_signal_action,
> for example.

Sure, but then make all of them u32, or unsigned int, as that gets mixed
in below.

> > > +struct utrace_examiner {
> > > +/* private: */
> > > +	long state;
> > > +	unsigned long ncsw;
> > > +};
> >
> > Again, its not C++, if you want a private state like that, use an opaque
> > type, like:
> >
> > struct utrace_examiner;
> >
> > and only define the thing in utrace.c or something.
> 
> Then the caller of utrace_prepare_examine() has to alloc utrace_examiner
> somehow. I disagree here. But of course we can remove this comment.

Ah, right then simply drop the comment.

> > > +static bool utrace_task_alloc(struct task_struct *task)
> > > +{
> > > +	struct utrace *utrace = kmem_cache_zalloc(utrace_cachep, GFP_KERNEL);
> > > +	if (unlikely(!utrace))
> > > +		return false;
> > > +	spin_lock_init(&utrace->lock);
> > > +	INIT_LIST_HEAD(&utrace->attached);
> > > +	INIT_LIST_HEAD(&utrace->attaching);
> > > +	utrace->resume = UTRACE_RESUME;
> > > +	task_lock(task);
> > > +	if (likely(!task->utrace)) {
> > > +		/*
> > > +		 * This barrier makes sure the initialization of the struct
> > > +		 * precedes the installation of the pointer.  This pairs
> > > +		 * with smp_read_barrier_depends() in task_utrace_struct().
> > > +		 */
> > > +		smp_wmb();
> > > +		task->utrace = utrace;
> > > +	}
> > > +	task_unlock(task);
> > > +	/*
> > > +	 * That unlock after storing task->utrace acts as a memory barrier
> > > +	 * ordering any subsequent task->utrace_flags store afterwards.
> > > +	 * This pairs with smp_rmb() in task_utrace_struct().
> > > +	 */
> > > +	if (unlikely(task->utrace != utrace))
> > > +		kmem_cache_free(utrace_cachep, utrace);
> > > +	return true;
> > > +}
> >
> > Again, not sure we can pair an UNLOCK-barrier with a RMB. In fact, both
> > are NOPs on x86.
> 
> We can't. I think the comment is confusing. We need the barrier
> between setting "task->utrace = utrace" and changing ->utrace_flags.
> We have unlock+lock in between, this implies mb().

So this is the task_unlock() in utrace_task_alloc() and the
spin_lock(&utrace->lock) in utrace_add_engine() ?

Talk about non-obvious.

> > > +static inline int utrace_attach_delay(struct task_struct *target)
> > > +{
> > > +	if ((target->flags & PF_STARTING) &&
> > > +	    task_utrace_struct(current) &&
> > > +	    task_utrace_struct(current)->cloning != target)
> > > +		do {
> > > +			schedule_timeout_interruptible(1);
> > > +			if (signal_pending(current))
> > > +				return -ERESTARTNOINTR;
> > > +		} while (target->flags & PF_STARTING);
> > > +
> > > +	return 0;
> > > +}
> >
> > Quite gross this.. can't we key off the
> > tracehoook_report_clone_complete() and use a wakeup there?
> 
> Yes, it would be very nice to avoid this schedule_timeout_interruptible().
> But currently we don't see a simple solution, on the TODO list. But, to
> clarify, this case is very unlikely.

Use a global wait-queue and put a wakeup_all in
tracehook_report_clone_complete() or wherever that ends up in utrace?

> > Furthermore I'd add a function like:
> >
> > static struct utrace_engine_ops *
> > get_utrace_ops(struct utrace_engine *engine, unsigned long *flags)
> > {
> > 	*flags = engine->flags;
> > 	/*
> > 	 * 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.
> > 	 */
> > 	smp_rmb();
> > 	return engine->ops;
> > }
> >
> > to take out and explicitly comment that common bit.
> >
> > Also, I'm not quite sure on why we play so many barrier games, looking
> > at start_callback() we have 2 barriers in the callback loop, why not a
> > per engine lock?
> 
> Exactly to avoid the lock, I guess ;)

I'm really thinking this code ought to get simplified a lot, there's too
much non-obvious barriers.

Then, and only if performance numbers show it, add back some of these
optimizations, in simple small steps, that way its much easier to review
as well.

> > > +	/*
> > > +	 * In theory spin_lock() doesn't imply rcu_read_lock().
> > > +	 * Once we clear ->utrace_flags this task_struct can go away
> > > +	 * because tracehook_prepare_release_task() path does not take
> > > +	 * utrace->lock when ->utrace_flags == 0.
> > > +	 */
> > > +	rcu_read_lock();
> > > +	task->utrace_flags = flags;
> > > +	spin_unlock(&utrace->lock);
> > > +	rcu_read_unlock();
> >
> > yuck!
> >
> > why not simply keep a task reference over the utrace_reset call?
> 
> Yes, we could use get_task_struct() instead. Not sure this would
> be more clean, though.

For one it would allow getting rid of that insane assymetric locking.

> > > +static inline void finish_callback_report(struct task_struct *task,
> > > +					  struct utrace *utrace,
> > > +					  struct utrace_report *report,
> > > +					  struct utrace_engine *engine,
> > > +					  enum utrace_resume_action action)
> > > +{
> > > +	/*
> > > +	 * 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;
> > > +		return;
> > > +	}
> > > +
> > > +	if (action < report->action)
> > > +		report->action = action;
> > > +
> > > +	if (action != UTRACE_STOP) {
> > > +		if (action < report->resume_action)
> > > +			report->resume_action = action;
> > > +
> > > +		if (engine_wants_stop(engine)) {
> > > +			spin_lock(&utrace->lock);
> > > +			clear_engine_wants_stop(engine);
> > > +			spin_unlock(&utrace->lock);
> > > +		}
> >
> > Reads funny, but I guess it can only race the right way round?
> 
> Not sure I understand... could you explain?

It can only race with another thread also clearing the bit, not with one
setting the bit? Otherwise there's no guarantee its not set after that
if stmt.

> > > +void utrace_report_jctl(int notify, int what)
> > > +{
> > > +	struct task_struct *task = current;
> > > +	struct utrace *utrace = task_utrace_struct(task);
> > > +	INIT_REPORT(report);
> > > +
> > > +	spin_unlock_irq(&task->sighand->siglock);
> > > +
> > > +	REPORT(task, utrace, &report, UTRACE_EVENT(JCTL),
> > > +	       report_jctl, what, notify);
> > > +
> > > +	spin_lock_irq(&task->sighand->siglock);
> > > +}
> >
> > So much documentation, and non of it says that the JCTL (funny name btw)
> > callback is done holding siglock... tskk.
> 
> Not sure I understand, but we unlock ->siglock before REPORT(). If you mean
> that utrace_report_jctl() is called under ->siglock, then yes.

Apparently means I'm cross-eyed as I read it to lock before and unlock
after :-/


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-07 18:34     ` Peter Zijlstra
@ 2009-12-08 15:04       ` Oleg Nesterov
  2009-12-08 15:29         ` Peter Zijlstra
  2009-12-08 15:35         ` Peter Zijlstra
  0 siblings, 2 replies; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-08 15:04 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On 12/07, Peter Zijlstra wrote:
>
> On Tue, 2009-12-01 at 23:08 +0100, Oleg Nesterov wrote:
>
> > > > @@ -560,6 +625,20 @@ static inline void tracehook_report_deat
> > > >  					  int signal, void *death_cookie,
> > > >  					  int group_dead)
> > > >  {
> > > > +	/*
> > > > +	 * This barrier ensures that our caller's setting of
> > > > +	 * @task->exit_state precedes checking @task->utrace_flags here.
> > > > +	 * If utrace_set_events() was just called to enable
> > > > +	 * UTRACE_EVENT(DEATH), then we are obliged to call
> > > > +	 * utrace_report_death() and not miss it.  utrace_set_events()
> > > > +	 * uses tasklist_lock to synchronize enabling the bit with the
> > > > +	 * actual change to @task->exit_state, but we need this barrier
> > > > +	 * to be sure we see a flags change made just before our caller
> > > > +	 * took the tasklist_lock.
> > > > +	 */
> > > > +	smp_mb();
> > > > +	if (task_utrace_flags(task) & _UTRACE_DEATH_EVENTS)
> > > > +		utrace_report_death(task, death_cookie, group_dead, signal);
> > > >  }
> > >
> > > I don't think its allowed to pair a mb with a lock-barrier, since the
> > > lock barriers are semi-permeable.
> >
> > Could you clarify?
>
> According to memory-barriers.txt a mb can be paired with mb,wmb,rmb
> depending on the situation.
>
> For LOCK it states:
>
> (1) LOCK operation implication:
>
>      Memory operations issued after the LOCK will be completed after the LOCK
>      operation has completed.
>
>      Memory operations issued before the LOCK may be completed after the LOCK
>      operation has completed.
>
> Which is not something I can see making sense to pair with an mb.
>
> So either the comment is confusing and its again referring to an UNLOCK
> +LOCK pair, or there's something fishy

Ah. I missed your point because I didn't read the comment.

Hmm. And since I didn't read the comment I misunderstood this code. Now
I think the comment is wrong, and this mb() is not needed.

If utrace utrace_set_events() adds _UTRACE_DEATH_EVENTS bits, it does
this under read_lock(tasklist). This means tracehook_report_death()
must always see the flags change, the caller took write_lock(tasklist).

IOW, in _UTRACE_DEATH_EVENTS case

	utrace_set_events:

		read_lock(tasklist);
		if (!target->exit_state)
			target->utrace_flags |= UTRACE_EVENT(DEATH);
		read_unlock(tasklist);

	exit_notify:

		write_lock(tasklist);
		task->exit_state = EXIT_XXX;
		write_unlock(tasklist);

		if (target->utrace_flags & _UTRACE_DEATH_EVENTS)
			utrace_report_death();

It doesn't matter if the reading of ->utrace_flags can be reordered with
the setting of ->exit_state, in no way this LOAD can happen _before_ we
take tasklist for writing. And, if ->utrace_flags was already changed
before we take tasklist, since utrace_set_events() does this under the
same lock, we must see the change after write_unlock(tasklist).

Roland?

> > > >  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);
> > > >  }
> > >
> > > Sending an IPI implies the mb?
> >
> > Yes, but this has nothing to do with IPI. The caller, do_notify_resume(),
> > does:
> > 	clear_thread_flag(TIF_NOTIFY_RESUME);
> > 	tracehook_notify_resume:
> > 		if (task_utrace_flags(task))
> > 			utrace_resume();
> >
> > We should not read task_utrace_flags() before we clear TIF_NOTIFY_RESUME.
>
> Then this comment needs an update.. that wasn't at all clear to me.

OK.

> > > > +static inline struct utrace *task_utrace_struct(struct task_struct *task)
> > > > +{
> > > > +	struct utrace *utrace;
> > > > +
> > > > +	/*
> > > > +	 * This barrier ensures that any prior load of task->utrace_flags
> > > > +	 * is ordered before this load of task->utrace.  We use those
> > > > +	 * utrace_flags checks in the hot path to decide to call into
> > > > +	 * the utrace code.  The first attach installs task->utrace before
> > > > +	 * setting task->utrace_flags nonzero, with a barrier between.
> > > > +	 * See utrace_task_alloc().
> > > > +	 */
> > > > +	smp_rmb();
> > > > +	utrace = task->utrace;
> > > > +
> > > > +	smp_read_barrier_depends(); /* See utrace_task_alloc().  */
> > > > +	return utrace;
> > > > +}
> > >
> > > I spot two barriers here, but only 1 over in utrace_task_alloc(), hmm?
> >
> > smp_read_barrier_depends() pairs with utrace_task_alloc()->wmb().
> >
> > smp_rmb() is needed for another reason. Suppose the code does:
> >
> > 	if (task_utrace_flags() & SOMETHING)
> > 		do_something_with(task->utrace);
> >
> > if we race with utrace_attach_task(), we can see ->utrace_flags != 0
> > but task->utrace == NULL without rmb().
>
> Still not clear what we pair with.. There is no obvious barrier in
> utrace_attach_task() nor a comment referring to this site.

Yes, agreed, we should move (and improve) the comment from
utrace_task_alloc() to utrace_attach_task() or utrace_add_engine()
which changed ->utrace_flags, see below.

> > > > +static bool utrace_task_alloc(struct task_struct *task)
> > > > +{
> > > > +	struct utrace *utrace = kmem_cache_zalloc(utrace_cachep, GFP_KERNEL);
> > > > +	if (unlikely(!utrace))
> > > > +		return false;
> > > > +	spin_lock_init(&utrace->lock);
> > > > +	INIT_LIST_HEAD(&utrace->attached);
> > > > +	INIT_LIST_HEAD(&utrace->attaching);
> > > > +	utrace->resume = UTRACE_RESUME;
> > > > +	task_lock(task);
> > > > +	if (likely(!task->utrace)) {
> > > > +		/*
> > > > +		 * This barrier makes sure the initialization of the struct
> > > > +		 * precedes the installation of the pointer.  This pairs
> > > > +		 * with smp_read_barrier_depends() in task_utrace_struct().
> > > > +		 */
> > > > +		smp_wmb();
> > > > +		task->utrace = utrace;
> > > > +	}
> > > > +	task_unlock(task);
> > > > +	/*
> > > > +	 * That unlock after storing task->utrace acts as a memory barrier
> > > > +	 * ordering any subsequent task->utrace_flags store afterwards.
> > > > +	 * This pairs with smp_rmb() in task_utrace_struct().
> > > > +	 */
> > > > +	if (unlikely(task->utrace != utrace))
> > > > +		kmem_cache_free(utrace_cachep, utrace);
> > > > +	return true;
> > > > +}
> > >
> > > Again, not sure we can pair an UNLOCK-barrier with a RMB. In fact, both
> > > are NOPs on x86.
> >
> > We can't. I think the comment is confusing. We need the barrier
> > between setting "task->utrace = utrace" and changing ->utrace_flags.
> > We have unlock+lock in between, this implies mb().
>
> So this is the task_unlock() in utrace_task_alloc() and the
> spin_lock(&utrace->lock) in utrace_add_engine() ?

Yes, and see above. This UNLOCK+LOCK provides the necessary barrier.

> Talk about non-obvious.

Well, agreed. We should fix the comment, or just add the explicit mb().
I personally think the "good" comment is enough.

> > > > +struct utrace_engine_ops {
> > >
> > > > +	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);
> > >
> > > > +};
> > >
> > > Seems inconsistent on u32 vs enum utrace_resume_action.
> >
> > Well, this u32 can hold utrace_resume_action | utrace_signal_action,
> > for example.
>
> Sure, but then make all of them u32, or unsigned int, as that gets mixed
> in below.

Not sure I understand, but if you meant all these callbacks should
return int/long then I'd personally agree.

> > > > +static inline int utrace_attach_delay(struct task_struct *target)
> > > > +{
> > > > +	if ((target->flags & PF_STARTING) &&
> > > > +	    task_utrace_struct(current) &&
> > > > +	    task_utrace_struct(current)->cloning != target)
> > > > +		do {
> > > > +			schedule_timeout_interruptible(1);
> > > > +			if (signal_pending(current))
> > > > +				return -ERESTARTNOINTR;
> > > > +		} while (target->flags & PF_STARTING);
> > > > +
> > > > +	return 0;
> > > > +}
> > >
> > > Quite gross this.. can't we key off the
> > > tracehoook_report_clone_complete() and use a wakeup there?
> >
> > Yes, it would be very nice to avoid this schedule_timeout_interruptible().
> > But currently we don't see a simple solution, on the TODO list. But, to
> > clarify, this case is very unlikely.
>
> Use a global wait-queue and put a wakeup_all in
> tracehook_report_clone_complete() or wherever that ends up in utrace?

- First of all, can't resist, I think a global wait-queue for
  this is just "ugly by definition". OK, please ignore, this
  is non-technical and subjective.

- If we change tracehook_report_clone_complete() to do the wakeup,
  this wakeup must be unconditional, it should be done even if the
  forking thread is not traced.

The current code is extremly simple and works. Yes, yes, yes, any
schedule_timeout(1) in a loop asks for the better solution. I don't
know what Roland thinks, but as for me this problem is low priority,
currently I didn't really try to think how to make this code "better".
This case is very unlikely, and it is not a hot-path. This happens
when the unrelated process tries to attach to the new thread in the
middle of do_fork().

But there is another reason why personally I think we should improve
this code later (and the similar code in utrace_barrier). A few lines
below you wrote:

> > > Also, I'm not quite sure on why we play so many barrier games, looking
> > > at start_callback() we have 2 barriers in the callback loop, why not a
> > > per engine lock?
> >
> > Exactly to avoid the lock, I guess ;)
>
> I'm really thinking this code ought to get simplified a lot, there's too
> much non-obvious barriers.
>
> Then, and only if performance numbers show it, add back some of these
> optimizations, in simple small steps, that way its much easier to review
> as well.

and above you suggest to complicate utrace_attach_delay() before merging.

As for "in simple small steps", I agree, it would be much better. The
problem is, this code was developed out-of-tree. That is why we would
like to merge it asap, then do other changes which could be easily
reviewed.

Now, do you really mean we should throw out the working code, rewrite
it avoiding these barriers, and resubmit? Sure, everything is possible.
But this means another round of out-of-tree development with unclear
results.

Some barriers are easy, we can simply take utrace->lock. Some are not.
In no way (imho) we should use spinlocks in tracehooks. OK, we can
embed "struct utrace" back into task_struct, then it would be easy
to eliminate more barriers, not sure this would be a good change though.

> > > > +	/*
> > > > +	 * In theory spin_lock() doesn't imply rcu_read_lock().
> > > > +	 * Once we clear ->utrace_flags this task_struct can go away
> > > > +	 * because tracehook_prepare_release_task() path does not take
> > > > +	 * utrace->lock when ->utrace_flags == 0.
> > > > +	 */
> > > > +	rcu_read_lock();
> > > > +	task->utrace_flags = flags;
> > > > +	spin_unlock(&utrace->lock);
> > > > +	rcu_read_unlock();
> > >
> > > yuck!
> > >
> > > why not simply keep a task reference over the utrace_reset call?
> >
> > Yes, we could use get_task_struct() instead. Not sure this would
> > be more clean, though.
>
> For one it would allow getting rid of that insane assymetric locking.

Well, this is subjective, but I don't agree that

	get_task_struct(task);
	task->utrace_flags = flags;
	spin_unlock(&utrace->lock);
	put_task_struct(task);

looks better. We can move get_task_struct (or rcu_read_lock) up, but
then the code becomes less obvious. This get/lock is only needed for
spin_unlock(&utrace->lock).

I'd wish we had rcu_read_lock_in_atomic (or whatever) which could be
used under spinlocks...

That said, if you think get_task_struct() can help to merge utrace
I personally do not care much.

> > > > +static inline void finish_callback_report(struct task_struct *task,
> > > > +					  struct utrace *utrace,
> > > > +					  struct utrace_report *report,
> > > > +					  struct utrace_engine *engine,
> > > > +					  enum utrace_resume_action action)
> > > > +{
> > > > +	/*
> > > > +	 * 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;
> > > > +		return;
> > > > +	}
> > > > +
> > > > +	if (action < report->action)
> > > > +		report->action = action;
> > > > +
> > > > +	if (action != UTRACE_STOP) {
> > > > +		if (action < report->resume_action)
> > > > +			report->resume_action = action;
> > > > +
> > > > +		if (engine_wants_stop(engine)) {
> > > > +			spin_lock(&utrace->lock);
> > > > +			clear_engine_wants_stop(engine);
> > > > +			spin_unlock(&utrace->lock);
> > > > +		}
> > >
> > > Reads funny, but I guess it can only race the right way round?
> >
> > Not sure I understand... could you explain?
>
> It can only race with another thread also clearing the bit, not with one
> setting the bit? Otherwise there's no guarantee its not set after that
> if stmt.

We do not care if another thread (the owner of this engine) sets or clears
ENGINE_STOP in engine->flags. This can happen if the tracer is "insane" and
races with itself. Nothing bad can happen, the last change wins.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-08 15:04       ` Oleg Nesterov
@ 2009-12-08 15:29         ` Peter Zijlstra
  2009-12-08 16:31           ` Oleg Nesterov
  2009-12-08 15:35         ` Peter Zijlstra
  1 sibling, 1 reply; 37+ messages in thread
From: Peter Zijlstra @ 2009-12-08 15:29 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
> > > > > +       /*
> > > > > +        * In theory spin_lock() doesn't imply rcu_read_lock().
> > > > > +        * Once we clear ->utrace_flags this task_struct can go away
> > > > > +        * because tracehook_prepare_release_task() path does not take
> > > > > +        * utrace->lock when ->utrace_flags == 0.
> > > > > +        */
> > > > > +       rcu_read_lock();
> > > > > +       task->utrace_flags = flags;
> > > > > +       spin_unlock(&utrace->lock);
> > > > > +       rcu_read_unlock();
> > > >
> > > > yuck!
> > > >
> > > > why not simply keep a task reference over the utrace_reset call?
> > >
> > > Yes, we could use get_task_struct() instead. Not sure this would
> > > be more clean, though.
> >
> > For one it would allow getting rid of that insane assymetric locking.
> 
> Well, this is subjective, but I don't agree that
> 
>         get_task_struct(task);
>         task->utrace_flags = flags;
>         spin_unlock(&utrace->lock);
>         put_task_struct(task);
> 
> looks better. 

No, what I mean by assymetric locking is that utrace_reset() and
utrace_reap() drop the utrace->lock where their caller acquired it,
resulting in non-obvious like:

utrace_control()
{

  ...
  spin_lock(&utrace->lock);

  ...

  if (reset)
    utrace_reset(utrace);
  else
    spin_unlock(&utrace->lock);
}

If you take a task ref you can write the much saner:

utrace_control()
{
  ...
  spin_lock(&utrace->lock);
  ...
  if (reset)
    utrace_reset(utrace);

  spin_unlock(&utrace->lock);
}




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-08 15:04       ` Oleg Nesterov
  2009-12-08 15:29         ` Peter Zijlstra
@ 2009-12-08 15:35         ` Peter Zijlstra
  2009-12-08 17:51           ` Oleg Nesterov
  1 sibling, 1 reply; 37+ messages in thread
From: Peter Zijlstra @ 2009-12-08 15:35 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
> The
> problem is, this code was developed out-of-tree. That is why we would
> like to merge it asap, then do other changes which could be easily
> reviewed.
> 
> Now, do you really mean we should throw out the working code, rewrite
> it avoiding these barriers, and resubmit? Sure, everything is possible.
> But this means another round of out-of-tree development with unclear
> results. 

Out-of-tree development is bad, it having taken lot of effort is no
excuse for merging ugly.

Now, I'm not against barriers at all, but code that is as barrier heavy
as this, with such bad comments and no clear indication it was actually
worth using so many barriers make me wonder.

Barriers aren't free either, and having multiple such things in quick
succession isn't nessecarily faster than a lock, but much less obvious.




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-08 15:29         ` Peter Zijlstra
@ 2009-12-08 16:31           ` Oleg Nesterov
  2009-12-08 18:19             ` Peter Zijlstra
  0 siblings, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-08 16:31 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On 12/08, Peter Zijlstra wrote:
>
> On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
> >
> > Well, this is subjective, but I don't agree that
> >
> >         get_task_struct(task);
> >         task->utrace_flags = flags;
> >         spin_unlock(&utrace->lock);
> >         put_task_struct(task);
> >
> > looks better.
>
> No, what I mean by assymetric locking is that utrace_reset() and
> utrace_reap() drop the utrace->lock where their caller acquired it,
> resulting in non-obvious like:
>
> utrace_control()
> {
>
>   ...
>   spin_lock(&utrace->lock);
>
>   ...
>
>   if (reset)
>     utrace_reset(utrace);
>   else
>     spin_unlock(&utrace->lock);
> }

Agreed, the code like this never looks good.

> If you take a task ref you can write the much saner:
>
> utrace_control()
> {
>   ...
>   spin_lock(&utrace->lock);
>   ...
>   if (reset)
>     utrace_reset(utrace);
>
>   spin_unlock(&utrace->lock);
> }

No, get_task_struct() in utrace_reset() can't help, we should move
it into utrace_control() then. And in this case it becomes even more
subtle: it is needed because ->utrace_flags may be cleared inside
utrace_reset() and after that utrace_control()->spin_unlock() becomes
unsafe.

Also. utrace_reset() drops utrace->lock to call put_detached_list()
lockless. If we want to avoid the assymetric locking, every caller
should pass "struct list_head *detached" to utrace_reset(), drop
utrace->lock, and call put_detached_list().

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-08 15:35         ` Peter Zijlstra
@ 2009-12-08 17:51           ` Oleg Nesterov
  0 siblings, 0 replies; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-08 17:51 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On 12/08, Peter Zijlstra wrote:
>
> On Tue, 2009-12-08 at 16:04 +0100, Oleg Nesterov wrote:
> > The
> > problem is, this code was developed out-of-tree. That is why we would
> > like to merge it asap, then do other changes which could be easily
> > reviewed.
> >
> > Now, do you really mean we should throw out the working code, rewrite
> > it avoiding these barriers, and resubmit? Sure, everything is possible.
> > But this means another round of out-of-tree development with unclear
> > results.
>
> Out-of-tree development is bad, it having taken lot of effort is no
> excuse for merging ugly.
>
> Now, I'm not against barriers at all, but code that is as barrier heavy
> as this, with such bad comments and no clear indication it was actually
> worth using so many barriers make me wonder.

Well. First of all, I agree at least partly. If you ask me, I feel
that in any case utrace needs more cleanups (in fact, like almost
any code in kernel) even if we forget about the barriers. In no
way utrace is finished or perfect. I think that Roland won't argue ;)

But. It would be much easier to do the futher development step by
step, patch by patch, which the changelogs, with the possibilty to
have the review. And it is much easier to change the code which is
already used by people. And, cleanups/simplifications are the most
hard part of the development.

However, of course I can't "prove" that the current code is "good
enough" for merging.

> Barriers aren't free either, and having multiple such things in quick
> succession isn't nessecarily faster than a lock, but much less obvious.

It is hardly possible to argue.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-08 16:31           ` Oleg Nesterov
@ 2009-12-08 18:19             ` Peter Zijlstra
  2009-12-08 18:37               ` Oleg Nesterov
  2009-12-13 20:48               ` Roland McGrath
  0 siblings, 2 replies; 37+ messages in thread
From: Peter Zijlstra @ 2009-12-08 18:19 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On Tue, 2009-12-08 at 17:31 +0100, Oleg Nesterov wrote:

> > If you take a task ref you can write the much saner:
> >
> > utrace_control()
> > {
> >   ...
> >   spin_lock(&utrace->lock);
> >   ...
> >   if (reset)
> >     utrace_reset(utrace);
> >
> >   spin_unlock(&utrace->lock);
> > }
> 
> No, get_task_struct() in utrace_reset() can't help, we should move
> it into utrace_control() then. And in this case it becomes even more
> subtle: it is needed because ->utrace_flags may be cleared inside
> utrace_reset() and after that utrace_control()->spin_unlock() becomes
> unsafe.

The task->utrace pointer is cleaned up on
free_task()->tracehook_free_task()->utrace_free_task(), so by holding a
ref on the task, we ensure ->utrace stays around, and we can do
spin_unlock(), right?

> Also. utrace_reset() drops utrace->lock to call put_detached_list()
> lockless. If we want to avoid the assymetric locking, every caller
> should pass "struct list_head *detached" to utrace_reset(), drop
> utrace->lock, and call put_detached_list().

All that seems to do is call ->release() and kmem_cache_free()s the
utrace_engine thing, why can't that be done with utrace->lock held?

But yeah, passing that list along does seem like a better solution.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-08 18:19             ` Peter Zijlstra
@ 2009-12-08 18:37               ` Oleg Nesterov
  2009-12-13 20:48               ` Roland McGrath
  1 sibling, 0 replies; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-08 18:37 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Alexey Dobriyan, Ananth Mavinakayanahalli, Christoph Hellwig,
	Frank Ch. Eigler, Ingo Molnar, Roland McGrath, linux-kernel,
	utrace-devel

On 12/08, Peter Zijlstra wrote:
>
> On Tue, 2009-12-08 at 17:31 +0100, Oleg Nesterov wrote:
>
> > > If you take a task ref you can write the much saner:
> > >
> > > utrace_control()
> > > {
> > >   ...
> > >   spin_lock(&utrace->lock);
> > >   ...
> > >   if (reset)
> > >     utrace_reset(utrace);
> > >
> > >   spin_unlock(&utrace->lock);
> > > }
> >
> > No, get_task_struct() in utrace_reset() can't help, we should move
> > it into utrace_control() then. And in this case it becomes even more
> > subtle: it is needed because ->utrace_flags may be cleared inside
> > utrace_reset() and after that utrace_control()->spin_unlock() becomes
> > unsafe.
>
> The task->utrace pointer is cleaned up on
> free_task()->tracehook_free_task()->utrace_free_task(), so by holding a
> ref on the task, we ensure ->utrace stays around, and we can do
> spin_unlock(), right?

Yes. That is why utrace_control() (which does unlock) should take the ref,
not utrace_reset().

> > Also. utrace_reset() drops utrace->lock to call put_detached_list()
> > lockless. If we want to avoid the assymetric locking, every caller
> > should pass "struct list_head *detached" to utrace_reset(), drop
> > utrace->lock, and call put_detached_list().
>
> All that seems to do is call ->release() and kmem_cache_free()s the
> utrace_engine thing, why can't that be done with utrace->lock held?

We can, but then ->release() will be called in atomic context. Utrace
tries hard to not "restrict" the module writers.

> But yeah, passing that list along does seem like a better solution.

Well, it has multiple callers, everyone will be complicated.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-08 18:19             ` Peter Zijlstra
  2009-12-08 18:37               ` Oleg Nesterov
@ 2009-12-13 20:48               ` Roland McGrath
  1 sibling, 0 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-13 20:48 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Oleg Nesterov, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

> All that seems to do is call ->release() and kmem_cache_free()s the
> utrace_engine thing, why can't that be done with utrace->lock held?

Calling ->release with a lock held is clearly insane, sorry.  It is true
that any engine-writer who does anything like utrace_* calls inside their
release callback is doing things the wrong way.  But guaranteeing that
simple mistakes result in spin-lock deadlocks just seems clearly wrong to
me.  A main point of the utrace API is to make it easier to work in this
space and help you avoid writing the pathological bugs.  Adding picayune
gotchas like this just does not help anyone.  No other API callback is made
holding some internal implementation lock, and making this one the sole
exception seems just obviously ill-advised on its face.  I can't really
imagine what a justification for such an obfuscation would be.

> But yeah, passing that list along does seem like a better solution.

So you find it cleaner to have each caller of utrace_reset take another
output parameter and be followed with the same exact source code duplicated
in each call site, than to have utrace_reset() do the unlock and then the
common code itself.  I guess there is no accounting for taste.  

We try not to get excited about trivia, so on matters like this one we will
do whatever the consensus of gate-keeping reviewers wants.  My patch to
implement your suggestion adds 13 lines of source and 134 bytes of compiled
text (x86-64).  Is that what you prefer?

I'll note that the code as it stands uses the __releases annotation for
sparse, as well as thoroughly documenting the locking details in comments.
I gather that clear explanation of the code is in your eyes no excuse for
ever writing code that requires one to actually read the comments.  I'm not
sure that attitude can ever be satisfied by any code that is nontrivial or
makes any attempts at optimization.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-01 19:54 ` Peter Zijlstra
                     ` (3 preceding siblings ...)
  2009-12-02 18:49   ` Oleg Nesterov
@ 2009-12-14  0:25   ` Roland McGrath
  2009-12-14 13:51     ` Peter Zijlstra
  2009-12-14 17:03     ` Oleg Nesterov
  4 siblings, 2 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-14  0:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Oleg Nesterov, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

I'm sorry for the delay.  I'm picking up with responding to the parts of
your review that I did not include in my first reply.  I appreciate very
much the discussion you've had with Oleg about the issues that I did not
address myself.  I look forward to your replies to my comments in that
first reply, which we have yet to see.

> Seems inconsistent on u32 vs enum utrace_resume_action.
> 
> Why force enum utrace_resume_action into a u32?

The first argument to almost all callbacks (all the ones made when the
task is alive) is called "action" and it's consistent that its low bits
contain an enum utrace_resume_action.  The argument is "u32 action" in
the report_signal and report_syscall_entry callbacks, where it combines
an enum utrace_resume_action with an enum utrace_{signal,syscall}_action
(respectively).  It would indeed be more consistent to use "u32 action"
throughout, but it seemed nicer not to have engine writers always
writing "utrace_resume_action(action)" for all the cases where there are
no other bits in there.

The return value is a mirror of the "u32 action" argument.  In many
calls, it has only an enum utrace_resume_action in it.  But in some it
combines that with another enum utrace_*_action.  There I went for
consistency (and less typing) in the return type, since it doesn't make
any difference to how you have to write the code in your callback
function.  The main reason I used "u32" at all instead of "unsigned int"
is just its shortness for less typing.

I don't really mind changing these details to whatever people think is
best.  The other people writing code to use the utrace API may have more
opinions than I do.  I guess it could even be OK to make the return
value and "action" argument always a plain enum utrace_resume_action,
and use a second in/out "enum utrace_{signal,syscall}_action *"
parameter in those particular calls.  But that does put some more
register pressure and loads/stores into this API.

> Seems inconsistent in the bitfield type, also it feels like that 3 the 7
> and the enum should be more tightly integrated, maybe add:
> 
> UTRACE_RESUME_MAX
> 
> #define UTRACE_RESUME_BITS (ilog2(UTRACE_RESUME_MAX))
> #define UTRACE_RESUME_MASK ((1 << UTRACE_RESUME_BITS) - 1)

Yes, that's a good cleanup.  Thanks.
(ilog2(7) is 2, so ilog2() + 1 is what you meant.)

> > +static struct utrace_engine *matching_engine(
[...]
> The function does a search, suggesting the function name ought to have
> something like find or search in it.

Ok, I'll make it find_matching_engine.

> Quite gross this.. can't we key off the
> tracehoook_report_clone_complete() and use a wakeup there?

Yes, we intended to clean this up at some point later.  But doing that
is just a distraction and complication right now so we put it off.  For
this case, however, I suppose we could just punt for the initial version.

This code exists to support the special semantics of calling
utrace_attach_task() from inside the parent's report_clone() callback.
That guarantees the parent that it wins any race with any third thread
calling utrace_attach_task().  This guarantees it will be first attacher
in the callback order, but the general subject of callback order is
already something we think we will want to revisit in the future after
we have more experience with lots of different engines trying to work
together.  It's most meaningful when using the UTRACE_ATTACH_EXCLUSIVE
flag--then you can use UTRACE_ATTACH_EXCLUSIVE|UTRACE_ATTACH_MATCH_OPS
to synchronize with other threads trying to attach the same kind of
engine to a task, and give special priority in that to the engine that
attaches in report_clone() from tracing the parent.

Really I came up with this special semantics originally just with ptrace
in mind.  ptrace is an engine that wants to exclude other tracer threads
attaching asynchronously with the same kind of engine, and that wants to
give special priority on a child to the parent's tracer (to implement
PTRACE_O_TRACECLONE et al).  However, Oleg's current ptrace code still
relies on the old hard-coded locking kludges to exclude the separate
attachers and to magically privilege the auto-attach from the parent's
tracer.  So we are not relying on this special semantics yet.

We could just punt utrace_attach_delay() and remove the associated
documentation about the special rights of report_clone() calling
utrace_attach_task().  If we decide it helps clean things up later when
we finish more cleanup of the ptrace world, then we can add the fancy
semantics back in later.

> Does this really need the inline?

It has one caller and that call is unconditional.

> Asymmetric locking like this is really better not done, and looking at
> the callsites its really no bother to clean that up, arguably even makes
> them saner.

By "assymetric" you mean that utrace_reap releases a lock (as the
__releases annotation indicates).  As should be obvious from the code, the
unlock is done before the loop that does ->report_reap callbacks and
utrace_engine_put() (which can make ->release callbacks).  Surely you are
not suggesting that all these callbacks should be made with a spin lock
held, because that would obviously be quite insane.

I tried splitting utrace_reap() into two functions, so the callers make the
first call, then unlock, and then make the second call.  Both callers do
this identically, so this just replaces 
		utrace_reap(task, utrace);
with:
		prepare_utrace_reap(task, utrace);
		spin_unlock(&utrace->lock);
		finish_utrace_reap(task, utrace);
in two places.  That change adds 13 source lines and 71 bytes of compiled
text (x86-64).  Is that what you had in mind?

> You could codify locking assumptions like here using:
> 
>   lockdep_assert_held(&utrace->lock);
> 
> Saves a comment and actually validates the assumption.

Ok, that is fine with me.

> > +	/*
> > +	 * If ptrace is among the reasons for this stop, do its
> > +	 * notification now.  This could not just be done in
> > +	 * ptrace's own event report callbacks because it has to
> > +	 * be done after we are in TASK_TRACED.  This makes the
> > +	 * synchronization with ptrace_do_wait() work right.
> > +	 */
> > +	ptrace_notify_stop(task);
> 
> Well, this is a bit disappointing isn't it? So we cannot implement
> ptrace on utrace without special purpose hooks?

It's more of an issue that ptrace is built around special-purpose hooks
in wait.  We do intend to clean this up later.  But it is as much about
cleaning up the remaining deep insanity of the old ptrace implementation
as about giving utrace better facilities for this wrinkle of
synchronization.  I don't doubt that the utrace API will get some
changes and improvements along the way as we move incrementally to all
of the ptrace internals being done in as clean and sane fashion as the
legacy ptrace userland ABI makes possible.  But Oleg has not yet gotten
to that part of the the ptrace cleanup, and the actual problem that
necessitates this kludge for ptrace is not an issue at all for many
other uses of utrace that don't have to tie into a broken old model of
things.  So being perfectly clean here is not something we should even
think we know how best to do yet, since there has been so little real
call for it.  It would be counterproductive to make this perfection an
obstacle to incremental merging of the current utrace pieces that
already enable other kinds of new functionality.

> If its a programming error, WARN_ON might be appropriate, no point in
> being nice about it.

Sure, except that any WARN_ON shows up as "oops in utrace.c" and then
people think the bug is in utrace rather than in the caller.

> Seriously ugly, again. Use a wakeup where appropriate.

> Its not entirely clear why we can check pending_attach outside of the
> utrace->lock and not be racy.

I think it can be racy sometimes but that does not matter.  
Maybe Oleg can verify my logic here.  If it's right, he can
add some comments to make it more clear.

There is only a very limited sort of "timeliness" guarantee about
getting your callbacks after utrace_attach_task()+utrace_set_events().
If you know somehow that the task was definitely still in TASK_STOPPED
or TASK_TRACED after utrace_attach_task() returned, then your engine
gets all possible callbacks starting from when it resumes.  Otherwise,
you can use utrace_control() with UTRACE_REPORT to ask to get some
callback "pretty soon".  The only callback events you are ever 100%
guaranteed about (after success return from utrace_set_events()) are for
DEATH and REAP, which have an unconditional lock-and-check before making
engine callbacks.

In the stopped cases, there are lots of locks and barriers and things
after resuming.  (Oleg?)

In the "pretty soon" case, that means set_notify_resume:
	if (!test_and_set_tsk_thread_flag(task, TIF_NOTIFY_RESUME))
		kick_process(task);
i.e. IPI after test_and_set.  The test_and_set implies an smp_mb().
So it should be the case that the set of utrace->pending_attach was seen
before the set of TIF_NOTIFY_RESUME.  In a race where the tracee just
saw utrace->pending_attach==0, then it has TIF_NOTIFY_RESUME set still
(or again), and so will go around again before getting back to user mode.

> > +	if (!engine_wants_stop(engine)) {
> > +		spin_lock(&utrace->lock);
> > +		/*
> > +		 * If utrace_control() came in and detached us
> > +		 * before we got the lock, we must not stop now.
> > +		 */
> > +		if (unlikely(engine->ops == &utrace_detached_ops))
> > +			report->detaches = true;
> > +		else
> > +			mark_engine_wants_stop(task, engine);
> > +		spin_unlock(&utrace->lock);
> > +	}
> > +}
> 
> I'm pretty sure that inline isn't really needed.

You mean mark_engine_wants_stop?  You prefer repeating the two lines of
code to using a helper to encapsulate the magic?  Really?

> Simply cond_resched() is sufficient, but that comment sucks, as it
> doesn't mention _why_ it is a good place.
> 
> It seems to turn out that finish_callback() is always the last thing we
> do in the engine iterations in REPORT_CALLBACKS() and
> utrace_get_signal().

Oh, sorry.  I didn't realize it wasn't obvious that finish_callback() is
called after every engine callback, given its name.  I've changed it to:

	/*
	 * We've just done an engine callback.  These are allowed to sleep,
	 * though all well-behaved ones restrict that to blocking kalloc()
	 * or quickly-acquired mutex_lock() and the like.  This is a good
	 * place to make sure tracing engines don't introduce too much
	 * latency under voluntary preemption.
	 */
	might_sleep();

> Also the documentation needs more whitespace, its very hard to digest in
> its current form.

Please make specific suggestions of exactly where you want what changes.  I
tend to use paragraph breaks between groups of sentences that work together
interdependently to communicate a single idea, like they taught me to write
English in elementary school.  In a few cases, I think the kernel-doc
formatting might force you to avoid extra blank lines or else you wind up
with the wrong kinds of grouping in HTML output or something (it's been a
while since I wrote some of the longer kernel-doc comments, and at the time
I looked carefully at how the make htmldocs and make mandocs results came
out to make them readable that way).  

Of course the purpose of comments and kernel-doc is to communicate clearly.
So I am happy to amend the comments in whatever fashions make them more
effective.  But you will have to cite exactly what you want.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14  0:25   ` Roland McGrath
@ 2009-12-14 13:51     ` Peter Zijlstra
  2009-12-14 17:41       ` Oleg Nesterov
  2009-12-16 11:18       ` Roland McGrath
  2009-12-14 17:03     ` Oleg Nesterov
  1 sibling, 2 replies; 37+ messages in thread
From: Peter Zijlstra @ 2009-12-14 13:51 UTC (permalink / raw)
  To: Roland McGrath
  Cc: Oleg Nesterov, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

On Sun, 2009-12-13 at 16:25 -0800, Roland McGrath wrote:
> I'm sorry for the delay.  I'm picking up with responding to the parts of
> your review that I did not include in my first reply.  I appreciate very
> much the discussion you've had with Oleg about the issues that I did not
> address myself.  I look forward to your replies to my comments in that
> first reply, which we have yet to see.

Yeah, no worries, I'm not too quick these days myself..

> > Seems inconsistent on u32 vs enum utrace_resume_action.
> > 
> > Why force enum utrace_resume_action into a u32?
> 
> The first argument to almost all callbacks (all the ones made when the
> task is alive) is called "action" and it's consistent that its low bits
> contain an enum utrace_resume_action.  The argument is "u32 action" in
> the report_signal and report_syscall_entry callbacks, where it combines
> an enum utrace_resume_action with an enum utrace_{signal,syscall}_action
> (respectively).  It would indeed be more consistent to use "u32 action"
> throughout, but it seemed nicer not to have engine writers always
> writing "utrace_resume_action(action)" for all the cases where there are
> no other bits in there.

C does implicit casts from enum to integer types, right? So always using
u32 here would not impose any extra typing on the user, or am I missing
something subtle here?

> The return value is a mirror of the "u32 action" argument.  In many
> calls, it has only an enum utrace_resume_action in it.  But in some it
> combines that with another enum utrace_*_action.  There I went for
> consistency (and less typing) in the return type, since it doesn't make
> any difference to how you have to write the code in your callback
> function.  The main reason I used "u32" at all instead of "unsigned int"
> is just its shortness for less typing.
> 
> I don't really mind changing these details to whatever people think is
> best.  The other people writing code to use the utrace API may have more
> opinions than I do.  I guess it could even be OK to make the return
> value and "action" argument always a plain enum utrace_resume_action,
> and use a second in/out "enum utrace_{signal,syscall}_action *"
> parameter in those particular calls.  But that does put some more
> register pressure and loads/stores into this API.

I don't mind the sharing of the argument, it just looked odd to have the
u32/unsigned int/enum thing intermixed, since you care about typing
length (as good a criteria as any) I'd just be lazy and make everything
u32 ;-)

> > Quite gross this.. can't we key off the
> > tracehoook_report_clone_complete() and use a wakeup there?
> 
> Yes, we intended to clean this up at some point later.  But doing that
> is just a distraction and complication right now so we put it off.  For
> this case, however, I suppose we could just punt for the initial version.
> 
> This code exists to support the special semantics of calling
> utrace_attach_task() from inside the parent's report_clone() callback.
> That guarantees the parent that it wins any race with any third thread
> calling utrace_attach_task().  

> This guarantees it will be first attacher
> in the callback order, but the general subject of callback order is
> already something we think we will want to revisit in the future after
> we have more experience with lots of different engines trying to work
> together.  

> It's most meaningful when using the UTRACE_ATTACH_EXCLUSIVE
> flag -- then you can use UTRACE_ATTACH_EXCLUSIVE|UTRACE_ATTACH_MATCH_OPS
> to synchronize with other threads trying to attach the same kind of
> engine to a task, and give special priority in that to the engine that
> attaches in report_clone() from tracing the parent.

I broke the text so it reads easier for me, it might be me, it might not
be proper English -- I'm not a native speaker -- but this is an example
of what you asked for below.

The thing is, your sentences are rather long, with lots of sub-parts and
similar. I find I need a break after digesting a few such things.

As to the content, can't you accomplish the same thing by processing
such exclusive parent registration before exposing the child in the
pid-hash? Right before cgroup_fork_callback() in
kernel/fork.c:copy_process() seems like the ideal site.

> Really I came up with this special semantics originally just with ptrace
> in mind.  ptrace is an engine that wants to exclude other tracer threads
> attaching asynchronously with the same kind of engine, and that wants to
> give special priority on a child to the parent's tracer (to implement
> PTRACE_O_TRACECLONE et al).  However, Oleg's current ptrace code still
> relies on the old hard-coded locking kludges to exclude the separate
> attachers and to magically privilege the auto-attach from the parent's
> tracer.  So we are not relying on this special semantics yet.
> 
> We could just punt utrace_attach_delay() and remove the associated
> documentation about the special rights of report_clone() calling
> utrace_attach_task().  If we decide it helps clean things up later when
> we finish more cleanup of the ptrace world, then we can add the fancy
> semantics back in later.

Best would be to fix up the utrace-ptrace implementation and get rid of
those other kludges I think, not sure.. its all a bit involved and I'm
not at all sure I'm fully aware of all the ptrace bits.

> > Does this really need the inline?
> 
> It has one caller and that call is unconditional.

Won't gcc inline it anyway in that case?

> > Asymmetric locking like this is really better not done, and looking at
> > the callsites its really no bother to clean that up, arguably even makes
> > them saner.
> 
> By "assymetric" you mean that utrace_reap releases a lock (as the
> __releases annotation indicates).  As should be obvious from the code, the
> unlock is done before the loop that does ->report_reap callbacks and
> utrace_engine_put() (which can make ->release callbacks).  Surely you are
> not suggesting that all these callbacks should be made with a spin lock
> held, because that would obviously be quite insane.

Because there can be many engines attached? 

> I tried splitting utrace_reap() into two functions, so the callers make the
> first call, then unlock, and then make the second call.  Both callers do
> this identically, so this just replaces 
> 		utrace_reap(task, utrace);
> with:
> 		prepare_utrace_reap(task, utrace);
> 		spin_unlock(&utrace->lock);
> 		finish_utrace_reap(task, utrace);
> in two places.  That change adds 13 source lines and 71 bytes of compiled
> text (x86-64).  Is that what you had in mind?

Or in case of utrace_reap() maybe push the spin_lock() into it?

> > > +	/*
> > > +	 * If ptrace is among the reasons for this stop, do its
> > > +	 * notification now.  This could not just be done in
> > > +	 * ptrace's own event report callbacks because it has to
> > > +	 * be done after we are in TASK_TRACED.  This makes the
> > > +	 * synchronization with ptrace_do_wait() work right.
> > > +	 */
> > > +	ptrace_notify_stop(task);
> > 
> > Well, this is a bit disappointing isn't it? So we cannot implement
> > ptrace on utrace without special purpose hooks?
> 
> It's more of an issue that ptrace is built around special-purpose hooks
> in wait.  We do intend to clean this up later.  But it is as much about
> cleaning up the remaining deep insanity of the old ptrace implementation
> as about giving utrace better facilities for this wrinkle of
> synchronization.  

> I don't doubt that the utrace API will get some
> changes and improvements along the way as we move incrementally to all
> of the ptrace internals being done in as clean and sane fashion as the
> legacy ptrace userland ABI makes possible.  But Oleg has not yet gotten
> to that part of the the ptrace cleanup, and the actual problem that
> necessitates this kludge for ptrace is not an issue at all for many
> other uses of utrace that don't have to tie into a broken old model of
> things.  

> So being perfectly clean here is not something we should even
> think we know how best to do yet, since there has been so little real
> call for it.  It would be counterproductive to make this perfection an
> obstacle to incremental merging of the current utrace pieces that
> already enable other kinds of new functionality.

Well, yes and no. Also I'm in no way a gate-keeper for acceptance of
this code, I just went through it and pointed out things I found 'odd'
about it.

The major improvement this utrace stuff brings over the old ptrace is
that it fully multiplexes the task tracing bits, however if the new bit
isn't powerful enough to express all of the old bits with that then that
seems to take the shine of the new bits.

I'm well aware that ptrace had some quirky bits in, and this might well
be one of the crazier parts of it, but to the un-initiated reviewer (me)
this could have done with a comment explaining exactly why this
particular site is not worth properly abstracting etc..

That is, you're presenting a patch for merger and have the wish that
people read it, yet half the comments on the rather brittle barrier
logic were incomplete or even flat out wrong and things like this are
not explained.

That does not paint a convincing picture.

> > If its a programming error, WARN_ON might be appropriate, no point in
> > being nice about it.
> 
> Sure, except that any WARN_ON shows up as "oops in utrace.c" and then
> people think the bug is in utrace rather than in the caller.

Not if the comment right above the WARN_ON() says that its a clueless
caller.. but if you're really worried about it, use something like:

WARN(cond, "Dumb-ass caller\n");

> > Its not entirely clear why we can check pending_attach outside of the
> > utrace->lock and not be racy.
> 
> I think it can be racy sometimes but that does not matter.  
> Maybe Oleg can verify my logic here.  If it's right, he can
> add some comments to make it more clear.
> 
> There is only a very limited sort of "timeliness" guarantee about
> getting your callbacks after utrace_attach_task()+utrace_set_events().
> If you know somehow that the task was definitely still in TASK_STOPPED
> or TASK_TRACED after utrace_attach_task() returned, then your engine
> gets all possible callbacks starting from when it resumes.  

> Otherwise,
> you can use utrace_control() with UTRACE_REPORT to ask to get some
> callback "pretty soon".  The only callback events you are ever 100%
> guaranteed about (after success return from utrace_set_events()) are for
> DEATH and REAP, which have an unconditional lock-and-check before making
> engine callbacks.

OK, so in this case its a best effort thing, and any races are
non-destructive.

> In the stopped cases, there are lots of locks and barriers and things
> after resuming.  (Oleg?)
> 
> In the "pretty soon" case, that means set_notify_resume:
> 	if (!test_and_set_tsk_thread_flag(task, TIF_NOTIFY_RESUME))
> 		kick_process(task);
> i.e. IPI after test_and_set.  The test_and_set implies an smp_mb().
> So it should be the case that the set of utrace->pending_attach was seen
> before the set of TIF_NOTIFY_RESUME. 

Not exactly sure where the matching rmb() would come from in
start_report() and friends -- task_utrace_struct() ?

>  In a race where the tracee just
> saw utrace->pending_attach==0, then it has TIF_NOTIFY_RESUME set still
> (or again), and so will go around again before getting back to user mode.
> 
> > > +	if (!engine_wants_stop(engine)) {
> > > +		spin_lock(&utrace->lock);
> > > +		/*
> > > +		 * If utrace_control() came in and detached us
> > > +		 * before we got the lock, we must not stop now.
> > > +		 */
> > > +		if (unlikely(engine->ops == &utrace_detached_ops))
> > > +			report->detaches = true;
> > > +		else
> > > +			mark_engine_wants_stop(task, engine);
> > > +		spin_unlock(&utrace->lock);
> > > +	}
> > > +}
> > 
> > I'm pretty sure that inline isn't really needed.
> 
> You mean mark_engine_wants_stop?  You prefer repeating the two lines of
> code to using a helper to encapsulate the magic?  Really?

No,

+static inline void finish_callback_report(struct task_struct *task,

That function looks rather large for an inline, and if its a single
callsite gcc will inline it anyway due to that static thing.

> > Simply cond_resched() is sufficient, but that comment sucks, as it
> > doesn't mention _why_ it is a good place.
> > 
> > It seems to turn out that finish_callback() is always the last thing we
> > do in the engine iterations in REPORT_CALLBACKS() and
> > utrace_get_signal().
> 
> Oh, sorry.  I didn't realize it wasn't obvious that finish_callback() is
> called after every engine callback, given its name.  I've changed it to:

Yeah, the name does seem to suggest some 'finish' of sorts, but it
wasn't clear until I traced its callchain back a little that it was the
tail of the for-each-engine loop.

> 	/*
> 	 * We've just done an engine callback.  These are allowed to sleep,
> 	 * though all well-behaved ones restrict that to blocking kalloc()
> 	 * or quickly-acquired mutex_lock() and the like.  This is a good
> 	 * place to make sure tracing engines don't introduce too much
> 	 * latency under voluntary preemption.
> 	 */
> 	might_sleep();

Right, might_sleep() captures more cases.

> > Also the documentation needs more whitespace, its very hard to digest in
> > its current form.
> 
> Please make specific suggestions of exactly where you want what changes.  I
> tend to use paragraph breaks between groups of sentences that work together
> interdependently to communicate a single idea, like they taught me to write
> English in elementary school.  

> In a few cases, I think the kernel-doc
> formatting might force you to avoid extra blank lines or else you wind up
> with the wrong kinds of grouping in HTML output or something (it's been a
> while since I wrote some of the longer kernel-doc comments, and at the time
> I looked carefully at how the make htmldocs and make mandocs results came
> out to make them readable that way).  
> 
> Of course the purpose of comments and kernel-doc is to communicate clearly.
> So I am happy to amend the comments in whatever fashions make them more
> effective.  But you will have to cite exactly what you want.

Right, so I've broken up some of the longer paragraphs, including the
penultimate quoted one, in order to illustrate what I meant. Like said
before, it might just be me.

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14  0:25   ` Roland McGrath
  2009-12-14 13:51     ` Peter Zijlstra
@ 2009-12-14 17:03     ` Oleg Nesterov
  2009-12-14 19:44       ` Roland McGrath
  1 sibling, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-14 17:03 UTC (permalink / raw)
  To: Roland McGrath
  Cc: Peter Zijlstra, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

On 12/13, Roland McGrath wrote:
>
> > Its not entirely clear why we can check pending_attach outside of the
> > utrace->lock and not be racy.
>
> I think it can be racy sometimes but that does not matter.
> Maybe Oleg can verify my logic here.  If it's right, he can
> add some comments to make it more clear.
>
> There is only a very limited sort of "timeliness" guarantee about
> getting your callbacks after utrace_attach_task()+utrace_set_events().
> If you know somehow that the task was definitely still in TASK_STOPPED
> or TASK_TRACED after utrace_attach_task() returned, then your engine
> gets all possible callbacks starting from when it resumes.  Otherwise,
> you can use utrace_control() with UTRACE_REPORT to ask to get some
> callback "pretty soon".  The only callback events you are ever 100%
> guaranteed about (after success return from utrace_set_events()) are for
> DEATH and REAP, which have an unconditional lock-and-check before making
> engine callbacks.

Yes, I think this is correct. It is fine to miss ->pending_attach == T,
and in any case the new attacher can come right after the check, even
if it was checked under utrace->lock.

It is important that the tracee can't miss, say, UTRACE_REPORT request
(as you already explained), and every time the tracee clears ->resume
it calls splice_attaching().

> In the stopped cases, there are lots of locks and barriers and things
> after resuming.  (Oleg?)

Every time the tracee resumes after TASK_TRACED it uses utrace->lock
to synchronize with utrace_control/etc, it must see any changes.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14 13:51     ` Peter Zijlstra
@ 2009-12-14 17:41       ` Oleg Nesterov
  2009-12-14 19:31         ` Oleg Nesterov
  2009-12-16 11:18       ` Roland McGrath
  1 sibling, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-14 17:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Roland McGrath, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

On 12/14, Peter Zijlstra wrote:
>
> > > Quite gross this.. can't we key off the
> > > tracehoook_report_clone_complete() and use a wakeup there?
> >
> > Yes, we intended to clean this up at some point later.  But doing that
> > is just a distraction and complication right now so we put it off.  For
> > this case, however, I suppose we could just punt for the initial version.
> >
> > This code exists to support the special semantics of calling
> > utrace_attach_task() from inside the parent's report_clone() callback.
> > That guarantees the parent that it wins any race with any third thread
> > calling utrace_attach_task().
>
> > This guarantees it will be first attacher
> > in the callback order, but the general subject of callback order is
> > already something we think we will want to revisit in the future after
> > we have more experience with lots of different engines trying to work
> > together.
>
> > It's most meaningful when using the UTRACE_ATTACH_EXCLUSIVE
> > flag -- then you can use UTRACE_ATTACH_EXCLUSIVE|UTRACE_ATTACH_MATCH_OPS
> > to synchronize with other threads trying to attach the same kind of
> > engine to a task, and give special priority in that to the engine that
> > attaches in report_clone() from tracing the parent.
>
> As to the content, can't you accomplish the same thing by processing
> such exclusive parent registration before exposing the child in the
> pid-hash? Right before cgroup_fork_callback() in
> kernel/fork.c:copy_process() seems like the ideal site.

I thought about this too, but there are some complications. Just for
example, what if copy_process() fails after we already reported the
new child was attached. And, the new child is not properly initialized
yet, it doesn't even have the valid pid/real_parent/etc. Just imagine
a callback wants to record task_pid_vnr(). Or it decides to send a
fatal signal (even private) to the new tracee.

> Best would be to fix up the utrace-ptrace implementation and get rid of
> those other kludges I think, not sure.. its all a bit involved and I'm
> not at all sure I'm fully aware of all the ptrace bits.

It is not that utrace-ptrace is buggy. We try to preserve the current
semantics. Yes, we can move this kludge to ptrace layer, but I am not
sure about other UTRACE_ATTACH_EXCLUSIVE engines.

If we move this to ptrace, then we can probably mark the new child
as "ptrace_attach() should fail, because we are going to auto-attach".
But in this case we need multiple hooks in do_fork() path again, like
the old ptrace does, while utrace needs only one.

> The major improvement this utrace stuff brings over the old ptrace is
> that it fully multiplexes the task tracing bits, however if the new bit
> isn't powerful enough to express all of the old bits with that then that
> seems to take the shine of the new bits.

Note that it would be easy to add another callback, and hide this
special case. But we should think twice before doing this.

> I'm well aware that ptrace had some quirky bits in, and this might well
> be one of the crazier parts of it, but to the un-initiated reviewer (me)
> this could have done with a comment explaining exactly why this
> particular site is not worth properly abstracting etc..

Well, agreed.

> > In the "pretty soon" case, that means set_notify_resume:
> > 	if (!test_and_set_tsk_thread_flag(task, TIF_NOTIFY_RESUME))
> > 		kick_process(task);
> > i.e. IPI after test_and_set.  The test_and_set implies an smp_mb().
> > So it should be the case that the set of utrace->pending_attach was seen
> > before the set of TIF_NOTIFY_RESUME.
>
> Not exactly sure where the matching rmb() would come from in
> start_report() and friends -- task_utrace_struct() ?

I am a bit confused...

As Roland said, we don't have any "timing" guarantees, and we can't have.
Whatever we do, the tracee can miss, say, ->report_syscall_entry() event
even if it does a system call "after" utrace_set_events(UTRACE_EVENT_SYSCALL),
this is fine.

But it shouldn't miss TIF_NOTIFY_RESUME/signal_pending/etc. I mean,
"sooner or later" it must hanlde the signal or TIF_NOTIFY_RESUME. And in
this case we can't miss ->pending_attach.

IOW, we must ensure that if ever clear TIF_NOTIFY_RESUME we must not
miss ->pending_attach, correct? and for this case we have mb() after
clear_thread_flag(). Perhaps instead we should add mb__after_clear_bit()
into arch/ hooks, but this needs a lot of arch-dependent changes.



And, btw, the usage of ->replacement_session_keyring looks racy,
exactly because (without utracee) we done have the necessary barriers
on both sides.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14 17:41       ` Oleg Nesterov
@ 2009-12-14 19:31         ` Oleg Nesterov
  2009-12-14 19:42           ` Roland McGrath
  0 siblings, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-14 19:31 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Roland McGrath, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

On 12/14, Oleg Nesterov wrote:
>
> IOW, we must ensure that if ever clear TIF_NOTIFY_RESUME we must not
> miss ->pending_attach, correct? and for this case we have mb() after
> clear_thread_flag(). Perhaps instead we should add mb__after_clear_bit()
> into arch/ hooks, but this needs a lot of arch-dependent changes.

Cough. And I always read this "rmb" as "mb". Even when I changed
the comment to explain that we need a barrier between clear bit
and read flags, I didn't notice it is in fact rmb...

I guess we need the trivial fix, Roland?

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14 19:31         ` Oleg Nesterov
@ 2009-12-14 19:42           ` Roland McGrath
  0 siblings, 0 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-14 19:42 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Peter Zijlstra, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

> On 12/14, Oleg Nesterov wrote:
> >
> > IOW, we must ensure that if ever clear TIF_NOTIFY_RESUME we must not
> > miss ->pending_attach, correct? and for this case we have mb() after
> > clear_thread_flag(). Perhaps instead we should add mb__after_clear_bit()
> > into arch/ hooks, but this needs a lot of arch-dependent changes.

Since it's utrace/tracehook code that relies on the barrier I think it
makes sense to have it in tracehook_notify_resume() or utrace_resume().
The arch requirement is having done clear_thread_flag() beforehand, so the
arch-independent code can reasonably assume whatever semantics that is
guaranteed to have.

> Cough. And I always read this "rmb" as "mb". Even when I changed
> the comment to explain that we need a barrier between clear bit
> and read flags, I didn't notice it is in fact rmb...
> 
> I guess we need the trivial fix, Roland?

You're the barrier man, send me what changes it should get.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14 17:03     ` Oleg Nesterov
@ 2009-12-14 19:44       ` Roland McGrath
  2009-12-14 20:24         ` Oleg Nesterov
  0 siblings, 1 reply; 37+ messages in thread
From: Roland McGrath @ 2009-12-14 19:44 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Peter Zijlstra, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

> Yes, I think this is correct. It is fine to miss ->pending_attach == T,
> and in any case the new attacher can come right after the check, even
> if it was checked under utrace->lock.

Right.

> It is important that the tracee can't miss, say, UTRACE_REPORT request
> (as you already explained), and every time the tracee clears ->resume
> it calls splice_attaching().

Right.

> > In the stopped cases, there are lots of locks and barriers and things
> > after resuming.  (Oleg?)
> 
> Every time the tracee resumes after TASK_TRACED it uses utrace->lock
> to synchronize with utrace_control/etc, it must see any changes.

And TASK_STOPPED?

Please send me patches to add whatever comments would make all this clear
enough to Peter when reading the code.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14 19:44       ` Roland McGrath
@ 2009-12-14 20:24         ` Oleg Nesterov
  2009-12-15  2:59           ` Roland McGrath
  0 siblings, 1 reply; 37+ messages in thread
From: Oleg Nesterov @ 2009-12-14 20:24 UTC (permalink / raw)
  To: Roland McGrath
  Cc: Peter Zijlstra, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

On 12/14, Roland McGrath wrote:
>
> > > In the stopped cases, there are lots of locks and barriers and things
> > > after resuming.  (Oleg?)
> >
> > Every time the tracee resumes after TASK_TRACED it uses utrace->lock
> > to synchronize with utrace_control/etc, it must see any changes.
>
> And TASK_STOPPED?

SIGCONT can wake up the TASK_STOPPED tracee. I don't think the tracer
should ever rely on TASK_STOPPED (utrace never does). If the tracer
needs the "really stopped" tracee we have UTRACE_STOP, and this means
TASK_TRACED.

But I am not sure I understand this part of discussion... In any case
the tracee should see any changes which were done before the wakeup.
But TASK_STOPPED can't guarantee the tracee won't be resumed until
the tracer wakes it up. Of course, TASK_TRACED can't prevent SIGKILL,
but in this case we should only care about "the tracee can't resume
until we drop utrace->lock" case.

Oleg.


^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14 20:24         ` Oleg Nesterov
@ 2009-12-15  2:59           ` Roland McGrath
  0 siblings, 0 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-15  2:59 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Peter Zijlstra, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

> SIGCONT can wake up the TASK_STOPPED tracee. I don't think the tracer
> should ever rely on TASK_STOPPED (utrace never does). If the tracer
> needs the "really stopped" tracee we have UTRACE_STOP, and this means
> TASK_TRACED.

Ah, yes.  utrace_control(task,,UTRACE_STOP) while task is in TASK_STOPPED
means turning it into TASK_TRACED.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: [RFC,PATCH 14/14] utrace core
  2009-12-14 13:51     ` Peter Zijlstra
  2009-12-14 17:41       ` Oleg Nesterov
@ 2009-12-16 11:18       ` Roland McGrath
  1 sibling, 0 replies; 37+ messages in thread
From: Roland McGrath @ 2009-12-16 11:18 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Oleg Nesterov, Alexey Dobriyan, Ananth Mavinakayanahalli,
	Christoph Hellwig, Frank Ch. Eigler, Ingo Molnar, linux-kernel,
	utrace-devel

> C does implicit casts from enum to integer types, right? So always using
> u32 here would not impose any extra typing on the user, or am I missing
> something subtle here?

No, that's right.  I had just been thinking of the documentation /
convenience issue.  I figured with u32 people might tend to think they
always had to write utrace_resume_action(action) like you do in
report_signal, or would want it to get the enum so e.g. you can write a
switch and have gcc give those warnings about covering all the enum cases.
But you have convinced me that the consistency of using u32 everywhere is
the what's really easiest to understand.

> I don't mind the sharing of the argument, it just looked odd to have the
> u32/unsigned int/enum thing intermixed, since you care about typing
> length (as good a criteria as any) I'd just be lazy and make everything
> u32 ;-)

That's good enough for me.

> As to the content, can't you accomplish the same thing by processing
> such exclusive parent registration before exposing the child in the
> pid-hash? Right before cgroup_fork_callback() in
> kernel/fork.c:copy_process() seems like the ideal site.

As Oleg mentioned, that would add some complications.  The task is not
really fully set up at that point and the clone might actually still fail.
The final stages where the clone can fail are necessarily inside some
important locks held while making the new task visible for lookup.

One of the key features of the utrace API is that callbacks are called in
uncomplicated contexts so you just don't have to worry about a lot of
strangeness and arcane constraints.  That means making such a callback
while holding any spin lock or suchlike is really out of the question.

So, either we have to make a callback where you suggest, before the task
really exists, or where we do now, after the task is visible to others.  An
unfinished task that doesn't yet have all its pointers in place, and still
might be freed before it could ever run, would add a whole lot of hair to
what the utrace API semantics would be.  If you get the callback that
early, then you can attach to it that early, and then you expect some
callbacks about it actually failing ever to exist.  And meanwhile, you
might have to know what you can and can't try to do with a task that is not
really set up yet.  It just seems like a really bad idea.

Hence, we are stuck with the post-clone callback being really post-clone so
that it's possible for other things in the system to see the new task and
try to utrace_attach it.  But, as I said, we are not actually relying on
having a way to rule that out at the utrace level today.  So I think we can
just take out this hack and reconsider it later when we have an active need.

> Best would be to fix up the utrace-ptrace implementation and get rid of
> those other kludges I think, not sure.. its all a bit involved and I'm
> not at all sure I'm fully aware of all the ptrace bits.

We haven't figured out all the best ways to clean up ptrace the rest of
the way yet.  We'd like to keep improving that incrementally after the
basics of utrace are in the tree.

> > [...] Surely you are
> > not suggesting that all these callbacks should be made with a spin lock
> > held, because that would obviously be quite insane.
> 
> Because there can be many engines attached? 

Because it's a callback API.  A callback is allowed to use mutex_lock(),
is expected to be preemptible, etc.  Having an interface where you let
somebody's function unwittingly run with spin locks held, preemption
disabled, and so forth, is just obviously a terrible interface.

> Or in case of utrace_reap() maybe push the spin_lock() into it?

I did a restructuring to make that possible.  IMHO it makes the control
flow a bit less clear.  But it came out a bit smaller in the text, so
I'll go with it.

> I'm well aware that ptrace had some quirky bits in, and this might well
> be one of the crazier parts of it, but to the un-initiated reviewer (me)
> this could have done with a comment explaining exactly why this
> particular site is not worth properly abstracting etc..

We'll add more comments there.

> Not if the comment right above the WARN_ON() says that its a clueless
> caller.. but if you're really worried about it, use something like:
> 
> WARN(cond, "Dumb-ass caller\n");

Oh, that's much better.  I've made all the WARN_ON's give some text.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2009-12-16 11:18 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-24 20:02 [RFC,PATCH 14/14] utrace core Oleg Nesterov
2009-11-24 20:32 ` Andi Kleen
2009-11-24 20:41   ` Oleg Nesterov
2009-11-24 21:26     ` Andi Kleen
2009-11-24 21:31       ` Frank Ch. Eigler
2009-11-24 21:34         ` Andi Kleen
2009-11-24 21:44       ` Oleg Nesterov
2009-11-25  8:46         ` Andi Kleen
2009-11-25 14:55           ` Oleg Nesterov
2009-11-25 16:00             ` Ingo Molnar
2009-11-25 21:50   ` Christoph Hellwig
2009-12-01 23:47   ` Roland McGrath
2009-12-01 19:54 ` Peter Zijlstra
2009-12-01 22:08   ` Oleg Nesterov
2009-12-07 18:34     ` Peter Zijlstra
2009-12-08 15:04       ` Oleg Nesterov
2009-12-08 15:29         ` Peter Zijlstra
2009-12-08 16:31           ` Oleg Nesterov
2009-12-08 18:19             ` Peter Zijlstra
2009-12-08 18:37               ` Oleg Nesterov
2009-12-13 20:48               ` Roland McGrath
2009-12-08 15:35         ` Peter Zijlstra
2009-12-08 17:51           ` Oleg Nesterov
2009-12-02  5:44   ` Roland McGrath
2009-12-02 18:34   ` Oleg Nesterov
2009-12-02 18:49   ` Oleg Nesterov
2009-12-05 19:14     ` Roland McGrath
2009-12-14  0:25   ` Roland McGrath
2009-12-14 13:51     ` Peter Zijlstra
2009-12-14 17:41       ` Oleg Nesterov
2009-12-14 19:31         ` Oleg Nesterov
2009-12-14 19:42           ` Roland McGrath
2009-12-16 11:18       ` Roland McGrath
2009-12-14 17:03     ` Oleg Nesterov
2009-12-14 19:44       ` Roland McGrath
2009-12-14 20:24         ` Oleg Nesterov
2009-12-15  2:59           ` Roland McGrath

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.