lkml.org 
[lkml]   [2009]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] utrace-based ftrace "process" engine, v2

* Frank Ch. Eigler <fche@redhat.com> wrote:

> Hi -
>
> On Sun, Mar 22, 2009 at 01:37:59AM +0300, Alexey Dobriyan wrote:
> > [...]
> > struct task_struct::utrace became embedded struct. This is good and
> > should remove quite a few of utrace bugs. Better late than never.
>
> Yeah.
>
> > However, "rewrite-ptrace-via-utrace" patch was omitted, so
> > almost noone can easily see by how much situation improved.
> > [...] Will ptrace(2) will be rewritten through utrace?
>
> Yes, I believe that is Roland's intent. I believe it was
> separated from the current suite of patches for staging purposes,
> to merge the most solid code up first. The code is available from
> the utrace git tree in the utrace-ptrace branch.

i think they should be submitted together.

Here's the histogram of utrace bugs on kerneloops.org:

2.6.27.5 1 x
2.6.27.15 1 x
2.6.27.12 2 x
2.6.27-rc4 2 x
2.6.26.6 1 x
2.6.26.5 43 x
2.6.26.3 1102 x
2.6.26.2 2 x
2.6.26.1 3 x
2.6.26 1 x
2.6.25 3 x

That peak in 2.6.26.3 is what i referred to. The latest F10 kernel
rpm is kernel-2.6.27.12-170.2.5.fc10, and it does include the
utrace-ptrace engine as well:

# grep UTRACE /boot/config-2.6.27.19-170.2.35.fc10.i686
CONFIG_UTRACE=y
CONFIG_UTRACE_PTRACE=y

So the bug i referred to was fixed and the bug count has gone down -
but still we have the utrace core submission here without any
(tested) mainline kernel usage of the core code.

My suggestion would be to:

- submit the ptrace-on-utrace engine as well (with Oleg's signoff?)

- perhaps also submit with a well-tested ftrace plugin that tries
to utilize _all_ aspects of utrace and ftrace (and hence gives
good and continuous burn-in testing via the ftrace bootup
self-tests, etc.)

ideally we want both, because:

- tracing corner-case bugs tend to be found much faster than ptrace
corner case bugs - partly because tracing is much more invasive
when activated system-wide.

- ptrace-over-utrace on the other hand utilizes utrace more deeply
than passive tracing ever can. (for example UML does full,
active virtualization via ptrace - this depth of functional
utrace usage is not possible via a tracing plugin.)

And i think the ptrace-via-utrace engine is actually fully ready,
just perhaps it was not submitted out of caution to keep the
logistics simple.

So i do think we've still got a shot at merging it, in this merge
window.

Ingo


\
 
 \ /
  Last update: 2009-03-22 11:29    [W:0.095 / U:3.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site