[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48B5658A.5000101@linux.vnet.ibm.com>
Date: Wed, 27 Aug 2008 16:32:42 +0200
From: Pierre Morel <pmorel@...ux.vnet.ibm.com>
To: Oleg Nesterov <oleg@...sign.ru>
CC: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com>,
Heiko Carstens <heicars2@...ux.vnet.ibm.com>,
sameske@...ux.vnet.ibm.com,
Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [RFC] [Patch 1/1] [Self Ptrace] System call notification with
self_ptrace
Oleg Nesterov wrote:
> On 08/26, Pierre Morel wrote:
>
>> Oleg Nesterov wrote:
>>
>>> We have some "->ptrace != 0" checks which can misunderstand this. Just
>>> for example, suppose that the task does sys_ptrace(PTRACE_SELF_ON) and
>>> then its parent dies. I guess in that case forget_original_parent()
>>> will hit BUG_ON(p->ptrace), no?
>>>
>>>
>>>
>> Yes you are right, I will take care of those cases.
>> I have the choice between:
>>
>> - tracking all references to the ptrace flags and add a test for PT_SELF
>> or a mask.
>>
>> - add a dedicated task_struct entry to hold the PT_SELF flag
>>
>
> Well, given that PT_SELF is exotic, neither choice looks very good, imho.
> But I am not expert and maintainer is cc'ed ;)
>
> I don't understand why this patch changes the x86's sys_sigaction().
>
Me neither, it should be only in handle_signal(), sorry it is a bug.
I am reworking the patch to take your remarks and the remarks
of Dave into account.
> 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.
> do_syscall_trace() filters out __NR_ptrace, this afaics means that the
> handler for SIGSYS can happily call sys_ptrace(PTRACE_SELF_OFF) and
> clear PT_SELF/TIF_SYSCALL_TRACE.
>
Yes.
The situation is the following: the ptrace_self implementation is not
compatible with the standard ptrace.
In fact it is a new tracing system using the infrastructure of
ptrace because it exist but it could leave completely separate from
ptrace.
> I must admit, personally I don't think the whole idea is good...
> And what if the user of PT_SELF is ptraced? The usage of TIF_SYSCALL_TRACE
> doesn't look "safe" in that case.
>
Yes, I will had exclusive access to the tracing so that one can not
use both ptrace and self_ptrace for the same process.
>
> Isn't it possible to implement this behaviour in the user space? If the
> task needs the PT_SELF behaviour, it can fork another process which will
> do PTRACE_ATTACH and then send the notifications to the task. We can use
> signals or something else.
>
In this case we would go back to standard ptrace behaviour.
The goal of the patch is to avoid the overhead of task switching
and IPC when instrumenting the process.
> Oleg.
>
>
thanks,
Pierre
--
=============
Pierre Morel
RTOS and Embedded Linux
--
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