lkml.org 
[lkml]   [2009]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[RFC PATCH 00/12 v3] ptrace: introduce task_struct->ptrace_cxt
    Changes:

    04/12: move kfree() outside of task_lock() in alloc_ptrace_context().
    But I misread your sugesstion:

    > task_lock(tsk);
    > if (likely(!tsk->ptrace_ctx)) {
    > tsk->ptrace_ctx = ptrace_ctx;
    > task_unlock(tsk);
    > return 0;
    > }
    >
    > task_unlock(tsk);
    > kfree(ptrace_ctx);

    Just can't do that. I hate multiple unlocks very much. So it
    becomes:

    task_lock(tsk);
    if (likely(!tsk->ptrace_ctx)) {
    tsk->ptrace_ctx = ptrace_ctx;
    ptrace_ctx = NULL;
    }
    task_unlock(tsk);
    kfree(ptrace_ctx);

    kfree(NULL) is specially allowed.


    05/12: Add the comment about tracehook_init_task to ptrace_init_task().

    I didn't change the original comment, but imho it is confusing.
    "immediately after adding @child to its parent's children list"
    does not matter. What does matter, is that it is called before
    this child is visible to the user-space and thus the unconditional
    ptrace_link() is safe: nobody could attach before us.


    08/12: No changes, but I think it better to change format_mca_init_stack()
    right now. Imho it has nothing to do with tracehooks and it is the
    last user of ->parent (except perhaps there are some in arch/ code
    which should be tracehookfied).


    09/12: Remove the stale "pt_" from the changelog.

    Oleg.



    \
     
     \ /
      Last update: 2009-05-31 00:55    [W:7.432 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site