Date: Mon, 16 May 2011 18:53:52 +0200
From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
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: <20110516165352.GA18727@redhat.com>
References: <201105152235.32073.vda.linux@googlemail.com> <20110516153122.GA15856@redhat.com> <20110516155253.GA20624@htj.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110516155253.GA20624@htj.dyndns.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2803
Lines: 77

On 05/16, Tejun Heo wrote:
>
> 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

Hmm. The can? sys_kill() sets si_code = 0, but tkill() or queueinfo()
can pass any si_code < 0. Also, the kernel can generate the signal
with si_code > 0.

> so, if si->si_code contains SIGTRAP |
> PTRACE_EVENT_* << 8,

But in this case (without PT_TRACE_EXEC) the tracee simply sends SIGTRAP
to itself. It will be reported later like a normal signal.

> > Yes. Except syscall entry/exit. But in this case SET_SIGINFO doesn't work
> > to add more confusion ;)
>
> Yeah, I hate these signal injections.

Welcome to the club!

> Maybe we can remove these if
> SEIZED?

Heh... I am not sure.

> > > 	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.

Hmm. What do you mean? tracehook_report_syscall_exit() can skip
ptrace_report_syscall() if step, but this is another story. And in this
case the tracee sends the real signal to itself, unlike
tracehook_signal_handler() which does ptrace_notify().

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

Agreed, it would be more clean/simple/understandable.

> > >     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.

Yes, agreed, we do not create the new one.

Oleg.

--
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/