Messages in this thread | | | Date | Wed, 27 Aug 2008 16:32:42 +0200 | From | Pierre Morel <> | 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
| |