DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        b=pgMbVILGPOlfnp5f1U1QsB5mMUXfYmqtr70ZaMm58ZgfX5q2wkoTaoD4zin7iODSJO
         P8U6227wSy+eWYCmoVnDk0nfQ/3jc5nXnsiKQYHbg+XcSgYDWZPmMmDRbQkEviiXEOjO
         Wu5jlSr/DRRltp1k8fGgzJewJoLEGptVwrbVA=
Date: Mon, 16 May 2011 17:52:53 +0200
From: Tejun Heo <tj@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Denys Vlasenko <vda.linux@googlemail.com>, jan.kratochvil@redhat.com,
        linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
        akpm@linux-foundation.org, indan@nul.nu
Subject: Re: Ptrace documentation, draft #1
Message-ID: <20110516155253.GA20624@htj.dyndns.org>
References: <201105152235.32073.vda.linux@googlemail.com>
 <20110516153122.GA15856@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110516153122.GA15856@redhat.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2986
Lines: 73

Hello,

I haven't read the whole thing yet but wanna comment on some.

On Mon, May 16, 2011 at 05:31:22PM +0200, Oleg Nesterov wrote:
> > Kernel delivers an extra SIGTRAP to tracee after execve syscall
> > returns. This is an ordinary signal (similar to one generated by kill
> > -TRAP), not a special kind of ptrace-stop. If PTRACE_O_TRACEEXEC option
> > is in effect, a PTRACE_EVENT_EXEC-stop is generated instead.
> >
> > ??? can this SIGTRAP be distinguished from "real" user-generated SIGTRAP
> >     by looking at its siginfo?
> 
> Afaics no. Well, except .si_pid shows that the signal was sent by the
> tracing process to itself.

If you do GETSIGINFO and look at si->si_code, user generated signals
can't have non-zero value there (assuming SETSIGINFO doesn't allow
uploading __SI_TRAP siginfo), so, if si->si_code contains SIGTRAP |
PTRACE_EVENT_* << 8, I think it reliably identifies a specific trap.
We probably want to add more PTRACE_EVENT_* so that each trap site can
be identified uniquely.  Note that the si_code is also returned as
exit_code on wait(2) and combined with CLD_TRAPPED ptrace traps should
be reliably identifiable.

> > Note that restarting ptrace commands issued in ptrace-stops other than
> > signal-delivery-stop do NOT inject a signal, even if sig is nonzero. No
> > error is reported either. This is a cause of confusion among ptrace
> > users.
> 
> Yes. Except syscall entry/exit. But in this case SET_SIGINFO doesn't work
> to add more confusion ;)

Yeah, I hate these signal injections.  Maybe we can remove these if
SEIZED?  Tracer might as well just do tkill().  I don't really see the
point of the signal injection feature.

> > Syscall-enter-stop and syscall-exit-stop are indistinguishable by
> > tracer.
> 
> Almost... at least on x86 rax = -ENOSYS in syscall-enter-stop.

We can add PTRACE_EVENT_* values if SEIZED.

> > 	ptrace(PTRACE_cmd, pid, 0, sig);
> > where cmd is CONT, DETACH, SYSCALL, SINGLESTEP, SYSEMU,
> > SYSEMU_SINGLESTEP. If tracee is in signal-delivery-stop, sig is the
> > signal to be injected. Otherwise, sig is ignored.
> 
> There is another special case. If the tracee single-stepps into the
> signal handler, it reports SIGTRAP as if it recieved this SIGNAL.
> But ptrace(PTRACE, ..., sig) doesn't inject after that.

Ditto as PTRACE_SYSCALL.  I think resuming from signal delivery trap
should be the only place where @data means signo.

> >     Is signal injected if they were in signal-delivery-stop?
> 
> Yes, The tracee resumes and handles the previously reported signal.

Please note that this one really isn't an injection.  It's just given
a chance to either suppress or alter a signal which is being
delivered.  It's not creating a new one.

Thank you.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/