[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/10] ptrace: implement PTRACE_SEIZE
On Thursday 26 May 2011 10:10:41, Tejun Heo wrote:
> > Btw. Speaking of SEIZE->execvd->INTERRUPT which makes the tracee see
> > a SIGTRAP.

I was told before that when SEIZE was in effect, there's no magic
SIGTRAP on exec.

> > Stupid question. Perhaps PTRACE_SEIZE should set
> > PT_TRACESYSGOOD | PT_TRACE_EXEC along with PT_SEIZED automatically?
> > PT_SEIZED implies the new behaviour anyway.
> Yeap, it makes sense to set them by default.

SYSGOOD makes sense, it just enables a means to distinguish syscall
SIGTRAPs from regular SIGTRAPs -- it doesn't cause child stops itself.
TRACE_EXEC, I'm not so sure. (and it appears to have been proposed
on the premise that SEIZE would still report the SIGTRAP).
Why would that make sense, and not TRACE_FORK, for example? I can imagine
a tracer only caring for syscall entry/exit, and not needing a special
event on exec. IMO, any kind of event that forces a child stop that
would't happen if the child wasn't traced should have to be enabled

Heck, GDB passes a subset of signals straight down to
the child without informing the user (e.g., see "handle SIGALRM"
command), and it would be an improvement in
the tracer-affects-tracee's-scheduling department to have a means to
let ptrace know a tracer isn't interested in such-and-such signals.
Conversely, going with the non-intrusive tracing theme, it would
even make sense for the tracer to have to request "let me know
about signals (all or a subset) sent to tracee too"

Pedro Alves

 \ /
  Last update: 2011-05-26 12:03    [W:0.134 / U:1.108 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site