lkml.org 
[lkml]   [2009]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 1/2] tracing/ftrace: syscall tracing infrastructure
    * Oleg Nesterov (oleg@redhat.com) wrote:
    > On 03/16, Mathieu Desnoyers wrote:
    > >
    > > utrace_add_engine()
    > > set_notify_resume(target);
    > >
    > > ok, so this is where the TIF_NOTIFY_RESUME thread flag is set. I notice
    > > that it is set asynchronously with the execution of the target thread
    > > (as I do with my TIF_KERNEL_TRACE thread flag).
    > >
    > > However, on x86_64, _TIF_DO_NOTIFY_MASK is only tested in
    > > entry_64.S
    > >
    > > int_signal:
    > > and
    > > retint_signal:
    > >
    > > code paths. However, if there is no syscall tracing to do upon syscall
    > > entry, the thread flags are not re-read at syscall exit and you will
    > > miss the syscall exit returning from your target thread if this thread
    > > was blocked while you set its TIF_NOTIFY_RESUME.
    >
    > Afaics, TIF_NOTIFY_RESUME is not needed to trace syscall entry/exit.
    > If engine wants the syscall tracing, utrace_set_events(UTRACE_SYSCALL_xxx)
    > sets TIF_SYSCALL_TRACE. And syscall_trace_enter/syscall_trace_leave call
    > tracehook_report_syscall_xxx().
    >
    > Oleg.

    I recall that TIF_SYSCALL_TRACE also suffers from the same problem as
    TIF_NOTIFY_RESUME if set asynchronously with the target thread's
    execution at least on x86_64 and arm. Do you take care to stop the
    target thread in utrace_set_events ?

    Mathieu

    >

    --
    Mathieu Desnoyers
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


    \
     
     \ /
      Last update: 2009-03-17 17:09    [W:0.052 / U:0.380 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site