Re: linux-next: add utrace tree

2010-01-29 Thread Ingo Molnar
* Ananth N Mavinakayanahalli ana...@in.ibm.com wrote: On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote: ... When we merged kprobes ~10 years ago we made the (rather bad) mistake of merging a raw, opaque facility and leaving 'the rest' up to some other entity. IBM

Re: linux-next: add utrace tree

2010-01-29 Thread Ingo Molnar
* Ananth N Mavinakayanahalli ana...@in.ibm.com wrote: On Fri, Jan 29, 2010 at 10:11:16AM +0100, Ingo Molnar wrote: * Ananth N Mavinakayanahalli ana...@in.ibm.com wrote: On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote: ... When we merged kprobes ~10 years

Re: linux-next: add utrace tree

2010-01-28 Thread Ingo Molnar
* Jim Keniston jkeni...@us.ibm.com wrote: On Wed, 2010-01-27 at 09:54 +0100, Ingo Molnar wrote: ... I think the best solution for user probes (by far) is to use a simplified in-kernel instruction emulator for the few common probes instruction. (Kprobes already partially decodes x86

Re: linux-next: add utrace tree

2010-01-27 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: On Tue, 2010-01-26 at 15:37 -0800, Linus Torvalds wrote: On Tue, 26 Jan 2010, Tom Tromey wrote: In non-stop mode (where you can stop one thread but leave the others running), gdb wants to have the breakpoints always inserted. So,

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-27 Thread Ingo Molnar
* Avi Kivity a...@redhat.com wrote: On 01/27/2010 10:24 AM, Ingo Molnar wrote: Not to mention that that process could wreck the trace data rendering it utterly unreliable. It could, but it also might not. Are we going to deny high performance tracing to users just because it doesn't

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

2010-01-27 Thread Ingo Molnar
* Avi Kivity a...@redhat.com wrote: If so then you ignore the obvious solution to _that_ problem: dont use INT3 at all, but rebuild (or re-JIT) your program with explicit callbacks. It's _MUCH_ faster than _any_ breakpoint based solution - literally just the cost of a function call

Re: linux-next: add utrace tree

2010-01-25 Thread Ingo Molnar
* Thomas Gleixner t...@linutronix.de wrote: On Mon, 25 Jan 2010, Steven Rostedt wrote: On Mon, 2010-01-25 at 10:12 -0800, Linus Torvalds wrote: But on the whole, I think it's actually worked out pretty well for them. I think the mainline kernel has improved in the process, but I

Re: linux-next: add utrace tree

2010-01-23 Thread Ingo Molnar
* Kyle Moffett k...@moffetthome.net wrote: On Fri, Jan 22, 2010 at 19:22, Linus Torvalds torva...@linux-foundation.org wrote: There are cases where we really _want_ to have common code. We want to have a common VFS interface because we want to show _one_ interface to user space across a

Re: linux-next: add utrace tree

2010-01-19 Thread Ingo Molnar
* Ingo Molnar mi...@elte.hu wrote: * Ananth N Mavinakayanahalli ana...@in.ibm.com wrote: On Wed, Jan 20, 2010 at 06:49:50AM +0100, Ingo Molnar wrote: Ingo, Note, i'm not yet convinced that this (and the rest: uprobes and systemtap, etc.) can go uptream in its present

Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

2009-12-09 Thread Ingo Molnar
* Frank Ch. Eigler f...@redhat.com wrote: [...] If the in-kernel gdb stub replaced kgdb functionally you'd hear no complaints from me. Let's leave it as an idea for the future. We came a full circle - that's the argument. We say overlap, duplication and incomplete implementation in

Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

2009-12-01 Thread Ingo Molnar
* Frank Ch. Eigler f...@redhat.com wrote: Hi - Only in name. One is highly invasive, for debugging the kernel across serial consoles. The other is highly noninvasive, for debugging user processes across normal userspace channels. They both happen to talk to gdb, but that's

Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

2009-11-30 Thread Ingo Molnar
* Frank Ch. Eigler f...@redhat.com wrote: peterz wrote: Hmm,. wouldn't it make much more sense to extend the current kgdb stub to include userspace debugging, providing an all-in-one solution? I think it would be much more powerful to be able to observe the full software stack and

Re: [RFC,PATCH 0/14] utrace/ptrace

2009-11-26 Thread Ingo Molnar
* Christoph Hellwig h...@infradead.org wrote: [...] Given that's it's pretty much too later for the 2.6.33 cycle anyway I'd suggest you make sure the remaining two major architectures (arm and mips) get converted, and if the remaining minor architectures don't manage to get their

Re: [RFC,PATCH 0/14] utrace/ptrace

2009-11-26 Thread Ingo Molnar
* Christoph Hellwig h...@infradead.org wrote: On Thu, Nov 26, 2009 at 10:10:52AM +0100, Ingo Molnar wrote: [...] Given that's it's pretty much too later for the 2.6.33 cycle anyway I'd suggest you make sure the remaining two major architectures (arm and mips) get converted

Re: [RFC,PATCH 14/14] utrace core

2009-11-25 Thread Ingo Molnar
* Oleg Nesterov o...@redhat.com wrote: Much better. But in this case please note that most of tracehooks just do: if (unlikely(task_utrace_flags(current) SOME_EVENT)) utrace_report_some_event(); I really don't understand why we shouldn't have

Re: seccomp via utrace

2009-03-24 Thread Ingo Molnar
* Roland McGrath rol...@redhat.com wrote: Here is a trivial module to implement the seccomp guts via utrace. I haven't tested it at all. (AFAIK it was only ever used by cpushare, and that project might be defunct now.) I'm not sure what Ingo had in mind for integrating this. If it's

Re: seccomp via utrace

2009-03-24 Thread Ingo Molnar
* Ananth N Mavinakayanahalli ana...@in.ibm.com wrote: nice! The simplification factor is already significant: 18 files changed, 116 insertions(+), 175 deletions(-) That is what we want - to remove special TIF flag uses and replace them with utrace driven machinery. Another

Re: seccomp via utrace

2009-03-24 Thread Ingo Molnar
* Roland McGrath rol...@redhat.com wrote: Regarding ptrace-via-utrace. What is the plan there? Am i looking the right branch: | earth4:~/linux.trees.git git diff --stat | linus/master..utrace/utrace-ptrace kernel/ptrace.c arch/x86/kernel/ptrace.c | kernel/ptrace.c | 803

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

2009-03-23 Thread Ingo Molnar
* Roland McGrath rol...@redhat.com wrote: kernel/utrace.c should probably be introduced as kernel/trace/utrace.c not kernel/utrace.c. It also overlaps pending work in the tracing tree and cooperation would be nice and desired. Of course I would like to cooperate with everyone. And of

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

2009-03-22 Thread Ingo Molnar
* Frank Ch. Eigler f...@redhat.com wrote: Hi - On Sat, Mar 21, 2009 at 04:45:01PM +0100, Ingo Molnar wrote: [...] To me personally there are two big direct usability issues with SystemTap: 1) It relies on DEBUG_INFO for any reasonable level of utility. Yes, it will limp

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

2009-03-22 Thread Ingo Molnar
* Linus Torvalds torva...@linux-foundation.org wrote: On Sat, 21 Mar 2009, Frank Ch. Eigler wrote: If testing utrace against its main application requires installation of a complete enterprise distro from a distro [...] This has *never* been a requirement. You guys are getting

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

2009-03-22 Thread Ingo Molnar
* Ingo Molnar mi...@elte.hu wrote: Total download size: 329 M That size of a _compressed_ debuginfo kernel package is obscene. We can fit 4 years of full Linux kernel Git history into that size - 60,000+ commits, full metadata and full 20 million lines of code flux included

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

2009-03-21 Thread Ingo Molnar
* 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

Re: implementation of syscall_get_error()

2008-09-05 Thread Ingo Molnar
Acked-by: Roland McGrath [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] --- include/asm-x86/syscall.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 6f29389..04c47dc 100644 --- a/include/asm-x86