[lkml]   [2011]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Ptrace documentation, draft #1

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.



 \ /
  Last update: 2011-05-16 19:29    [W:0.050 / U:26.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site