[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110516172058.GD20624@htj.dyndns.org>
Date: Mon, 16 May 2011 19:20:58 +0200
From: Tejun Heo <tj@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Denys Vlasenko <vda.linux@...glemail.com>,
jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
indan@....nu
Subject: Re: Ptrace documentation, draft #1
Hello,
On Mon, May 16, 2011 at 06:53:52PM +0200, Oleg Nesterov wrote:
> > 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.
Yeah, sure, not non-zero then, but it's still distinguishible, no?
> > 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.
Ah, okay, I missed the context. I thought we were talking about
GETSIGINFO after traps not the extra SIGTRAP after execve. Sorry
about that. :-)
> > Maybe we can remove these if SEIZED?
>
> Heh... I am not sure.
Yeah, I'm not sure either. I think the most reasonable solution would
be leaving them alone but strongly discourage their use.
> 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().
Please disregard. Still was fixated on GETSIGINFO.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists