[lkml]   [2012]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: syscall_regfunc() && TIF_SYSCALL_TRACEPOINT
    On 03/30, Steven Rostedt wrote:
    > On Fri, 2012-03-30 at 22:15 +0200, Oleg Nesterov wrote:
    > > But I don't really understand why do you think that "clear" is more
    > > important.
    > They are both important. But as I tend to consider performance when
    > tracing is off as critical, I'm more concerned about that. But both must
    > be fixed, because not reporting traces can confuse a developer.

    Ah, got it, thanks.

    I was going to send the simple patch we discussed, but suddenly I
    realized that I have another question.

    Why do we want to filter out the kernel threads in syscall_regfunc?

    From cc3b13c1 "tracing: Don't trace kernel thread syscalls"

    then it has no effect to trace the kernel thread calls
    to syscalls in that path.
    Setting the TIF_SYSCALL_TRACEPOINT flag is then useless for these.

    OK, but then it doesn't hurt? Or is there another reason why
    TIF_SYSCALL_TRACEPOINT is not desirable on kthread?

    The problem is ____call_usermodehelper() which execs the user-space
    task. This clears PF_KTHREAD (sets ->mm), but obviously if
    sys_tracepoint_refcount != 0 this is too late.

    So what do you think we should do,

    - keep this check

    - remove it

    - remove it in a separate patch

    - add the "sync with sys_tracepoint_refcount" hook
    before kernel_execve()



     \ /
      Last update: 2012-03-31 22:47    [W:0.020 / U:99.576 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site