Re: [PATCH 3/3] utrace-based ftrace "process" engine, v2

[Alexey Dobriyan <adobriyan@gmail.com>]

On Sun, Mar 22, 2009 at 01:37:49PM +0100, Ingo Molnar wrote:
> The ptrace bits and signoffs from Oleg and Alexey would certainly 
> help (me) in trusting it. (I've Cc:-ed Oleg and Alexey)

The further utrace stays away from mainline, the better.
That's from my experience with this code.

But let's see how ptrace(2) rewrite will look like because this is
the biggest thing that matters. All those cool virtual machines,
fancy tracers and what not aren't even comparable.

Right now with ptrace(2) rewrite the following is easily triggerable:

WARNING: at kernel/ptrace.c:515 ptrace_report_signal+0x2c1/0x2d0()
Pid: 4814, comm: exe Not tainted 2.6.29-rc8-utrace #1
Call Trace:
 [<c0126df1>] warn_slowpath+0x81/0xa0
 [<c014c359>] ? validate_chain+0xe9/0x1150
 [<c014d606>] ? __lock_acquire+0x246/0xa50
 [<c0232959>] ? __delay+0x9/0x10
 [<c014b8eb>] ? mark_held_locks+0x6b/0x80
 [<c03d3dd2>] ? _spin_unlock_irq+0x22/0x50
 [<c012fdd1>] ptrace_report_signal+0x2c1/0x2d0
 [<c012fb10>] ? ptrace_report_signal+0x0/0x2d0
 [<c0154a79>] utrace_get_signal+0x1c9/0x660
 [<c0135478>] get_signal_to_deliver+0x288/0x330
 [<c01029e9>] do_notify_resume+0xb9/0x890
 [<c017edd2>] ? cache_free_debugcheck+0x232/0x2f0
 [<c014957b>] ? trace_hardirqs_off+0xb/0x10
 [<c03d3d79>] ? _spin_unlock_irqrestore+0x39/0x70
 [<c01015a0>] ? sys_execve+0x40/0x60
 [<c017f139>] ? kmem_cache_free+0x89/0xc0
 [<c014baad>] ? trace_hardirqs_on_caller+0xfd/0x190
 [<c014bb4b>] ? trace_hardirqs_on+0xb/0x10
 [<c010340a>] work_notifysig+0x13/0x19

It looks like WARN_ON is just bogus, but who knows.