[lkml]   [2008]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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


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.


 \ /
  Last update: 2008-08-28 14:31    [W:0.059 / U:8.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site