On 08/26, Pierre Morel wrote:Me neither, it should be only in handle_signal(), sorry it is a bug.
Oleg Nesterov wrote:
We have some "->ptrace != 0" checks which can misunderstand this. JustYes you are right, I will take care of those cases.
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?
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().
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
do_syscall_trace() filters out __NR_ptrace, this afaics means that theYes.
handler for SIGSYS can happily call sys_ptrace(PTRACE_SELF_OFF) and
clear PT_SELF/TIF_SYSCALL_TRACE.
I must admit, personally I don't think the whole idea is good...Yes, I will had exclusive access to the tracing so that one can not
And what if the user of PT_SELF is ptraced? The usage of TIF_SYSCALL_TRACE
doesn't look "safe" in that case.
In this case we would go back to standard ptrace behaviour.
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.
Oleg.thanks,