Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace: implement PTRACE_SEIZE]

[Tejun Heo <tj@kernel.org>]

Hello, Jan.

On Sun, May 15, 2011 at 05:56:02PM +0200, Jan Kratochvil wrote:
> It was already addressed by me before so I will give more reasons:
> 	https://lkml.org/lkml/2011/3/1/309

Hmmm... I don't think the argument given in the message is valid.  The
new trap doesn't have any side effect (other than possible syscall
restart (or -EINTR failure) and performance overhead) so there
wouldn't be any problem from correctness POV and the code to SEIZE and
establish initial state would be simple.

> GDB already has mode `set observer on' (in this case we are interested in its
> part `set may-interrupt off') - see: $ info '(gdb)Observer Mode'
> 	# If you want to [...] observe program behavior without any chance of
> 	# disruption by GDB
> This is an increasingly requested feature as one of the ways of monitoring.

Hmmm... transparency.  Other than signal_wakeup (syscall restart /
-EINTR), there is no side effect of SEIZE - from transparency POV,
this should be considered fully transparent.  signal_wakeup can happen
anytime even without signals.  It's an integral part of the
programming interface.  I don't know.  Maybe.

> There are also requests to handle applications using 10000+ threads, which
> currently have problems with GDB.  One can imagine a needless
> waitpid+PTRACE_CONT is not a help.

Yeap, performance could be a legitimate concern but then again I'm not
sure here either - the whole thing is quite slow and not trapping on
SEIZE might not amount to all that much.  Again, maybe.

How long does it take to attach to / detach from 10000+ threads?  If
you don't do it serially, it shouldn't take that long.

> > Which trap will happen isn't fixed.  If other trap conditions exist (signal
> > delivery or group stop), they might be taken; otherwise, a trap with
> > exit_code SIGTRAP | (PTRACE_EVENT_INTERRUPT << 8) is taken.
> 
> What if PTRACE_INTERRUPT is called by tracer only after the tracee has stopped
> on a signal delivery?  It should be ignored in such case - as the first signal
> will not be PTRACE_EVENT_INTERRUPT.  (Sorry if you have stated it somewhere.)

I think you're somewhat confused here.  Well, ptrace manpage is pretty
confused too.  Those are different traps.  You can tell them apart
from userland and it doesn't matter which order or how many times
INTERRUPT occurs.

Thanks.

-- 
tejun