On 08/28, Pierre Morel wrote:May be, but very high compared to the operation to just
Oleg Nesterov wrote:
On 08/27, Pierre Morel wrote:It is right but brings the overhead of a syscall.
Oleg Nesterov wrote:Yes I see. But the signal handler for SIGSYS can fisrt do
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.
sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any
other syscall.
Well, this overhead is very small compared to the signal delivery.
ok, please read "set PTRACE_SELF_ON"With this patch PT_SELF is cleared on any signal. This doesn't lookIf the tracing application catches all signals before delivering
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".
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.