[lkml]   [2011]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 03/10] ptrace: implement PTRACE_SEIZE
    On Wed, May 18, 2011 at 11:55 AM, Tejun Heo <> wrote:
    > Hello, Denys.
    > On Wed, May 18, 2011 at 02:40:56AM +0200, Denys Vlasenko wrote:
    >> This makes PTRACE_EVENT_STOP similar to other PTRACE_EVENTs.
    >> The only difference is that it can't be set by PTRACE_SETOPTIONS
    >> as other events do, but activated implicitly by PTRACE_SEIZE.
    > Also by PTRACE_INTERRUPT and group stop.

    "Activating" meaning "enabling", not "causing". Only PTRACE_SEIZE
    enables PTRACE_EVENT_STOP.

    >> This made me thinking.
    >> How about making API even more similar to existing one?
    >> Create PTRACE_O_TRACESTOP, make it settable by PTRACE_SETOPTIONS too.
    >> Make PTRACE_SEIZE take the mask of PTRACE_O_xyz flags
    >> as data argument.
    >> If PTRACE_O_TRACESTOP is set, it works as you described above.
    >> If PTRACE_O_TRACESTOP is not set, then it works as good old PTRACE_ATTACH.
    >> In both cases, immediately at attach it sets opts a-la PTRACE_SETOPTIONS.
    >> We can even avoid introducing PTRACE_SEIZE at all, because
    >> currently PTRACE_ATTACH ignores its data argument.
    >> I know, I know, "this changes API", but did we ever promise
    >> that PTRACE_ATTACH with nonzero data arg is a valid usage?
    >> Also, I perused first 10 pages of google code search results
    >> and I see that everybody passes 0 or NULL.
    > But as SEIZE introduces behavior differences throughout ptrace
    > operation,
    > Similar issue with PTRACE_O_TRACESTOP. It won't only enable TRACESTOP
    > it will change other behaviors too

    All these differences revolve around making handling of stops
    and SIGCONT better. It seems fitting to the option name.

    PTRACE_SEIZE sets a flag somewhere "please convert
    group-stops into PTRACE_EVENT_STOPs".

    But, we *already have* ptrace op which performs this action
    of modifying (or adding) stops - it's PTRACE_SETOPTIONS.
    With PTRACE_O_TRACESYSGOOD it modifies syscall-stops.
    With PTRACE_O_TRACEEXEC - post-execve stop.
    With PTRACE_O_TRACEFORK it adds a stop after fork.

    Since we have this API, why not use it for the very similar
    concept of modifying group-stops too?

    > I think it's actually beneficial to use a distinctively new
    > request. It's not like it costs anything or we're short on request
    > number space.

    "Entities must not be multiplied beyond necessity"?


     \ /
      Last update: 2011-05-18 12:47    [W:2.716 / U:0.848 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site