lkml.org 
[lkml]   [2011]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH] Make PTRACE_SEIZE set ptrace options specified in data parameter
    On 09/07, Denys Vlasenko wrote:
    >
    > Make PTRACE_SEIZE set ptrace options specified in data parameter

    Personally I think this makes sense, and in fact I suggested this
    from the very beginning.

    Oh. But since we are goin to establish the API rules, this should
    be discussed.

    IIRC, Tejun disliked this idea. Tejun?

    > retval = -EIO;
    > - if (seize && !(flags & PTRACE_SEIZE_DEVEL))
    > - goto out;
    > + if (seize) {
    > + if ((flags & ~(long)PTRACE_O_MASK) != PTRACE_SEIZE_DEVEL)
    > + goto out;
    > + flags &= ~PTRACE_SEIZE_DEVEL;
    > + } else
    > + flags = 0;

    Personally I do not care, but this is against the coding-style rules. This
    should be

    } else {
    flags = 0;
    }

    Or, better,

    flags = 0;
    if (seize) {
    flags = ...
    }


    > @@ -263,7 +267,7 @@ static int ptrace_attach(struct task_struct *task, long request,
    > if (task->ptrace)
    > goto unlock_tasklist;
    >
    > - task->ptrace = PT_PTRACED;
    > + task->ptrace = PT_PTRACED | (flags << PT_OPT_FLAG_SHIFT);
    > if (seize)
    > task->ptrace |= PT_SEIZED;

    Hmm. Tejun, Denys, this doesn't look exactly right.

    I already thought about this before, but somehow I convinced myself
    this is fine.

    I think we should set both PT_PTRACED | PT_SEIZED "atomically", at
    once. Otherwise, say, the tracee can do do_jobctl_trap() in between,
    no? Nothing really bad can happen, but we shouldn't lose EVENT_STOP
    code.

    IOW, I think we need the small fix before this patch.

    Oleg.


    \
     
     \ /
      Last update: 2011-09-07 19:25    [W:0.034 / U:59.788 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site