[PATCH 0/7] utrace/ptrace

[PATCH 0/7] utrace/ptrace

[Oleg Nesterov]

Hello.

This is the new iteration of Roland's utrace patch, this time
with "rewrite-ptrace-via-utrace" + cleanups in utrace core.

This version tries to address some of Peter's comments.

Oleg.

Re: [PATCH 0/7] utrace/ptrace

[Andrew Morton]

On Fri, 18 Dec 2009 02:11:16 +0100
Oleg Nesterov <oleg@redhat.com> wrote:

> Hello.
> 
> This is the new iteration of Roland's utrace patch, this time
> with "rewrite-ptrace-via-utrace" + cleanups in utrace core.
> 

So... should we merge this?

I'll confess that I've rather forgotten why we might want this.

> It allows for multiple separate tracing engines to work
> in parallel without interfering with each other.  Higher-level tracing
> facilities can be implemented as loadable kernel modules using this layer.

That's a bit brief.  Do you have a nicer sales brochure?  What are
these "separate tracing engines" and what is their merge status and why
would we want any of them, for what purpose?  etc.

IOW: give us a reason!

Re: [PATCH 0/7] utrace/ptrace

[Oleg Nesterov]

On 12/22, Andrew Morton wrote:
>
> On Fri, 18 Dec 2009 02:11:16 +0100
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > It allows for multiple separate tracing engines to work
> > in parallel without interfering with each other.  Higher-level tracing
> > facilities can be implemented as loadable kernel modules using this layer.
>
> That's a bit brief.  Do you have a nicer sales brochure?  What are
> these "separate tracing engines" and what is their merge status and why
> would we want any of them, for what purpose?  etc.
>
> IOW: give us a reason!

First of all, utrace makes other things possible. gdbstub, nondestructive
core dump, uprobes, kmview, hopefully more. I didn't look at these projects
closely, perhaps other people can tell more. As for their merge status,
until utrace itself is merged it is very hard to develop them out of tree.

To me, even seccomp is the good example why utrace is useful. seccomp
is simple, but it needs hooks in arch/ hot pathes. Contrary, utrace-based
implementation is more flexible, simple, and it is completely "hidden"
behind utrace.

In my opinion, ptrace-utrace is another example. Once CONFIG_UTRACE
goes away, we can remove almost all ptrace-related code from core
kernel (and kill task_struct->ptrace/etc members).

ftrace/etc is excellent in many ways, but even if we need the simple
"passive" tracing it is not enough sometimes. And we have nothing else
except ptrace currently. But ptrace is so horrible and unfixeable, and
it has so many limitations. In fact, even the simple things like stop/
continue this thread/process are not trivial using ptrace, gdb/strace
have to do a lot of hacks to overcome ptrace's limitations, and some
of these hacks falls into "mostly works, but that is all" category.

Of course, I can't promise we will have the new gdb which explores
utrace facilities soon, but I think at leat utrace gives a chance.


Well. I had a lot of technical discussions with Roland about utrace,
but I never asked him why he created this thing ;) To me, utrace
looks like vfs. Currently we have the single and very poor "filesystem",
ptrace. Until we add the appropriate layer, we can't expect the
further improvements is this area.

Oleg.

Re: [PATCH 0/7] utrace/ptrace

[Roland McGrath]

> Well. I had a lot of technical discussions with Roland about utrace,
> but I never asked him why he created this thing ;) To me, utrace
> looks like vfs. Currently we have the single and very poor "filesystem",
> ptrace. Until we add the appropriate layer, we can't expect the
> further improvements is this area.

I think that is an excellent analogy, and it's one I've used before.

Oleg and I have had our hands pretty full just with the infrastructure
layer and with ptrace.  Having this layer in the kernel is what makes
it tractable for a lot of other people to collaborate on new features
in this space, and that's what we want to enable and accelerate.  
Some of those on the CC list have worked and are working on such
things, and I hope they will pipe up about those.

Given the date, I suspect we might not see much from anybody on this
(or anything) until January.  Myself, I expect to be largely offline
for the rest of the year.

As Oleg mentioned, I have a cleanup/reimplementation of seccomp using
utrace.  That is quite a trivial use--it demonstrates how easy the
utrace API makes it to do things like that, in contrast to previous
solutions with arch-specific assembly hacking and so forth.  I can
dust that patch off and post it if anybody cares.

Some other features based on utrace have been floating around for some
time, posted here before.  Those include uprobes, kmview, and the gdb
stub.  I don't which of those are quite ready for merging, but honing
and polishing them gets quite a lot more doable with utrace in the
tree instead of out.


Thanks,
Roland

Re: [PATCH 0/7] utrace/ptrace

[Andi Kleen]

> As Oleg mentioned, I have a cleanup/reimplementation of seccomp using
> utrace.  That is quite a trivial use--it demonstrates how easy the
> utrace API makes it to do things like that, in contrast to previous
> solutions with arch-specific assembly hacking and so forth.  I can
> dust that patch off and post it if anybody cares.

Do you have an estimate or better numbers how the overhead of 
seccomp-over-utrace compares to the current in-tree seccomp?

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH 0/7] utrace/ptrace

[Roland McGrath]

> Do you have an estimate or better numbers how the overhead of 
> seccomp-over-utrace compares to the current in-tree seccomp?

I never measured it.  I would estimate that any difference one way or
another is in the noise.  The point of seccomp is to run a process that
almost never makes any system calls.  The only effects of utrace for that
use are on the system call path itself, and the essential effects there
(i.e. taking the tracing path vs the hot path) are the same as what the old
seccomp implementation does.

If you have some example uses of seccomp or something that can serve as a
benchmark for it, I would be glad to measure the difference.


Thanks,
Roland

Re: [PATCH 0/7] utrace/ptrace

[caiqian]

> This is the new iteration of Roland's utrace patch, this time
> with "rewrite-ptrace-via-utrace" + cleanups in utrace core.

Tested-by: CAI Qian <caiqian@redhat.com>