Re: [PATCH 0/7] utrace/ptrace
On Fri, 18 Dec 2009 02:11:16 +0100 Oleg Nesterov o...@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 -mm] introduce tracehook_finish_jctl() helper
On Wed, 29 Jul 2009 04:01:40 +0200
Oleg Nesterov o...@redhat.com wrote:
(textually depends on signals-tracehook_notify_jctl-change.patch)
Introduce the empty inline tracehook_finish_jctl() helper called by
do_signal_stop() after wakeup.
Currently we lack the ability to report this state change.
Also fix the comment, it should be placed before schedule().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
include/linux/tracehook.h |9 +
kernel/signal.c |2 ++
2 files changed, 11 insertions(+)
--- __UTRACE/include/linux/tracehook.h~2_FINISH_JCTL 2009-07-29
03:10:10.0 +0200
+++ __UTRACE/include/linux/tracehook.h2009-07-29 03:51:42.0
+0200
@@ -521,6 +521,15 @@ static inline int tracehook_notify_jctl(
return notify ?: (current-ptrace PT_PTRACED) ? why : 0;
}
+/**
+ * tracehook_finish_jctl - report about return from job control stop
+ *
+ * This is called by do_signal_stop() after wakeup.
+ */
+static inline void tracehook_finish_jctl(void)
+{
+}
+
#define DEATH_REAP -1
#define DEATH_DELAYED_GROUP_LEADER -2
--- __UTRACE/kernel/signal.c~2_FINISH_JCTL2009-07-29 03:17:49.0
+0200
+++ __UTRACE/kernel/signal.c 2009-07-29 03:57:07.0 +0200
@@ -1735,12 +1735,12 @@ static int do_signal_stop(int signr)
read_unlock(tasklist_lock);
}
+ /* Now we don't run again until woken by SIGCONT or SIGKILL */
do {
schedule();
} while (try_to_freeze());
- /*
- * Now we don't run again until continued.
- */
+
+ tracehook_finish_jctl();
current-exit_code = 0;
Confused. This patch has no effect.
Re: [PATCH 3/3] utrace-based ftrace process engine, v2
So we need to work out what to do about utrace and I feel a need to hit the reset button on all this. Largely because I've forgotten everything and it was all confusing anyway. Could those who object to utrace please pipe up and summarise their reasons? Just to kick the can down the road a bit I merged the first two patches. The ftrace patch merged about as (un)successfully as one would expect.
Re: [PATCH 3/3] utrace-based ftrace process engine, v2
On Sat, 21 Mar 2009 08:43:01 +0100 Ingo Molnar mi...@elte.hu wrote: * Roland McGrath rol...@redhat.com wrote: From: Frank Ch. Eigler f...@redhat.com This is v2 of the prototype utrace-ftrace interface. This code is based on Roland McGrath's utrace API, which provides programmatic hooks to the in-tree tracehook layer. This new patch interfaces many of those events to ftrace, as configured by a small number of debugfs controls. Here's the /debugfs/tracing/process_trace_README: Please submit changes/enhancements to kernel/trace/* to the tracing tree maintainers (Steve and me) for review, testing and integration. Please also post patches against the latest tracing tree: http://people.redhat.com/mingo/tip.git/README uhm, this patch depends on the (large) utrace patch, which is not kernel/trace material. As this patch does not apply: Applying patch patches/utrace-based-ftrace-process-engine-v2.patch patching file include/linux/processtrace.h patching file kernel/trace/Kconfig Hunk #1 succeeded at 186 with fuzz 2 (offset 36 lines). patching file kernel/trace/Makefile Hunk #1 FAILED at 33. 1 out of 1 hunk FAILED -- rejects in file kernel/trace/Makefile patching file kernel/trace/trace.h Hunk #1 succeeded at 7 with fuzz 1. Hunk #2 FAILED at 31. Hunk #3 succeeded at 215 with fuzz 2 (offset 43 lines). Hunk #4 FAILED at 330. 2 out of 4 hunks FAILED -- rejects in file kernel/trace/trace.h patching file kernel/trace/trace_process.c Patch patches/utrace-based-ftrace-process-engine-v2.patch does not apply (enforce with -f) The rejects are trivial.
Re: [PATCH 2/3] utrace core
On Fri, 20 Mar 2009 18:41:40 -0700 (PDT) Roland McGrath rol...@redhat.com wrote: This adds the utrace facility, a new modular interface in the kernel for implementing user thread tracing and debugging. This fits on top of the tracehook_* layer, so the new code is well-isolated. The new interface is in linux/utrace.h and the DocBook utrace book describes it. 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. The new facility is made optional under CONFIG_UTRACE. When this is not enabled, no new code is added. It can only be enabled on machines that have all the prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK. In this initial version, utrace and ptrace do not play together at all. If ptrace is attached to a thread, the attach calls in the utrace kernel API return -EBUSY. If utrace is attached to a thread, the PTRACE_ATTACH or PTRACE_TRACEME request will return EBUSY to userland. The old ptrace code is otherwise unchanged and nothing using ptrace should be affected by this patch as long as utrace is not used at the same time. In the future we can clean up the ptrace implementation and rework it to use the utrace API. I'd be interested in seeing a bit of discussion regarding the overall value of utrace - it has been quite a while since it floated past. I assume that redoing ptrace to be a client of utrace _will_ happen, and that this is merely a cleanup exercise with no new user-visible features? The prototype utrace-ftrace interface seems to be more a cool toy rather than a serious new kernel feature (yes?) If so, what are the new killer utrace clients which would justify all these changes? Also, is it still the case that RH are shipping utrace? If so, for what reasons and what benefits are users seeing from it? And I recall that there were real problems wiring up the Feb 2007 version of utrace to the ARM architecture. Have those issues been resolved? Are any problems expected for any architectures? Thanks.
