[lkml]   [2011]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Proposal for ptrace improvements
    On Fri, Mar 04, 2011 at 07:12:50PM +0100, Jan Kratochvil wrote:
    > On Fri, 04 Mar 2011 18:07:37 +0100, Oleg Nesterov wrote:
    > > Suppose that the tracee reports, say, a signal after PTRACE_SEIZE/INTERRUPT.
    > > And this is possible anyway if the debugger races with kill(). Why this
    > > is bad?
    > I was asking if it is possible or if it could be avoided.

    First of all, if the conditions are distinguishible reliably, I think
    things should be fine. Also, after seizing, at least two conditions
    must be distinguishible immediately - whether the tracee was in group
    stop or just ptrace trapped, so I don't think guaranteeing single
    condition is feasible to begin with.

    > When the tracer has a function to attach a task it should be a self-sufficient
    > function returning the tracee in some normal task like after other events.
    > So the attach operation should neither leave pending some excessive signals
    > nor it should eat some normal vital signals (like PTRACE_EVENT_FORK).

    That was one of the reasons why I suggested PTRACE_SEIZE to be both
    attach and interrupt. In both cases, the possible states of the task
    would be exactly the same. As debugger is likely to travel various
    paths in the interrupt case regularly, it will be much easier to get
    it right and once you get that right, attach becomes right at no
    additional cost!

    > Sure the tracer can always handle it some way, ignore this signal,
    > remember if it has seen that signal etc. But if we design a new
    > ptrace interface it should be simple to use and it should not
    > suggest coding racy/buggy tracers.

    There's no signal to ignore. It might not be as simple as you fancy
    but will (at least strive to) be reliable and race-free. I think
    racy/buggy tracers have a lot more to do with lack of documentation
    and clear rules. Everyone is left to guess and everyone of course
    ends up with different conclusions. Let's add a detailed
    documentation of rules and subtleties.



     \ /
      Last update: 2011-03-06 11:41    [W:4.036 / U:1.276 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site