Messages in this thread | | | Date | Thu, 28 Aug 2008 16:32:42 +0400 | From | Oleg Nesterov <> | Subject | Re: [RFC] [Patch 1/1] [Self Ptrace] System call notification with self_ptrace |
| |
On 08/28, Pierre Morel wrote: > > Oleg Nesterov wrote: > >On 08/27, Pierre Morel wrote: > > > >>Oleg Nesterov wrote: > >> > >> > >>>On s390 the patch changes handle_signal(), this is not clear to me too. > >>> > >>> > >>The patch clears the trace flags before delivering the signal so > >>that the signal handler can use system call without bouncing again. > >> > > > >Yes I see. But the signal handler for SIGSYS can fisrt do > >sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any > >other syscall. > > > It is right but brings the overhead of a syscall.
Well, this overhead is very small compared to the signal delivery.
> >With this patch PT_SELF is cleared on any signal. This doesn't look > >right. Let's suppose that another signal comes in parallel with SIGSYS. > >It is very possible that the handler for that another signal will be > >called first, this handler can do some syscall which will be "missed". > > > > If the tracing application catches all signals before delivering > them to the instrumented original handler there is no problem, > the catching code can reset PTRACE_SELF_ON before calling the > instrumented application's original handler. > The instrumented code will then bounce as expected.
Sorry, can't understand the text above :(
OK, let's suppose the application does
ptrace(PTRACE_SELF_ON); ... syscall();
This "syscall()" above should trigger the handler for SIGSYS. But what if another signal (with handler) comes in between? In that case handle_signal() clears PT_SELF/TIF_SYSCALL_TRACE, this syscall() (or any other) doesn't send SIGSYS.
Oleg.
| |