Re: linux-next: add utrace tree

[Oleg Nesterov <oleg@redhat.com>]

On 01/21, Andrew Morton wrote:
>
> ptrace is a nasty, complex part of the kernel which has a long history
> of problems, but it's all been pretty quiet in there for the the past few
> years.

Well, yes, I'd say ptrace is "frozen". Nobody add new features/improvements,
only bugfixes.

> This leads one to expect that a rip-out-n-rewrite is a
> high-risk prospect.  So, quite reasonably, one looks for a good reason
> for taking such risk.

As it was already said, utrace was not created to just replace the current
ptrace.

However, speaking of ptrace, imho even ptrace-utrace is more flexible and
allows to improve this api easily.

Just for example, even attach and detach are not trivial to use from
user-space when it comes to multithread tracees. A one-liner patch for
ptrace-utrace can implement PTRACE_DETACH which doesn't need TASK_TRACED,
it is easy to avoid the initial SIGSTOP from attach (which doesn't always
work but strace/gdb relies on it).

Of course, I do not profess this is not posible with the current
implementation. But this will need more changes, and these changes will
touch the code outside of ptrace.c. And in fact I think that any
enhancements in this area will lead to rewrite of the current ptrace
code.

I must admit that personally I think the current ptrace api is unfixable,
we need the new one in the long term. It would be nice to just kill ptrace,
but this is not possible and that is why ptrace-utrace exists. And, if
nothing more, utrace allows to have both old and new ones without any
changes outside of ptrace/utrace code.

Oleg.