On Mon, Jul 12, 2010 at 08:37:29PM +0200, Oleg Nesterov wrote:
Hello.
Please see the attachment. Don't take this code seriously, this is
the early prototype and everything should be rewritten. It barely
uses utrace, only to stop the target.
(gdb) file /path/to/binary
(gdb)
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 ago we made the (rather bad) mistake of
merging a raw, opaque
On Thu, Jan 28, 2010 at 09:55:02AM +0100, Ingo Molnar wrote:
...
Lets compare the two cases via a drawing. Your current uprobes submission
does:
[kernel] do probe thing single-step trap
^| ^ |
|v |
On Wed, Jan 27, 2010 at 11:55:16AM +0100, Peter Zijlstra wrote:
On Wed, 2010-01-27 at 02:43 -0800, Linus Torvalds wrote:
On Wed, 27 Jan 2010, Peter Zijlstra wrote:
Right, so you're going to love uprobes, which does exactly that. The
current proposal is overwriting the target
On Wed, Jan 27, 2010 at 12:08:31PM +0100, Peter Zijlstra wrote:
On Wed, 2010-01-27 at 16:35 +0530, Ananth N Mavinakayanahalli wrote:
Probing RIP-relative instructions work just fine; there are fixups that
take care of it.
Ah my bad then, it was my understanding you simply bailed on those
On Mon, Jan 25, 2010 at 01:41:57PM -0800, Linus Torvalds wrote:
On Mon, 25 Jan 2010, Tom Tromey wrote:
...
* Support displaced stepping in the kernel; I think this would improve
performance when debugging in non-stop mode.
Don't we already do that at least on x86? Just doing a
On Sat, Jan 23, 2010 at 12:23:33PM +0100, Ingo Molnar wrote:
* Kyle Moffett k...@moffetthome.net wrote:
On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
torva...@linux-foundation.org wrote:
...
In that sense it might be better to fix/enhance ptrace, if there's interest.
I've written a
On Thu, Jan 21, 2010 at 05:28:42PM -0800, Linus Torvalds wrote:
On Thu, 21 Jan 2010, Andrew Morton wrote:
ptrace is a nasty, complex part of the kernel which has a long history
of problems, but it's all been pretty quiet in there for the the past few
years.
More importantly, we're
On Fri, Jan 22, 2010 at 12:32:32PM +0530, Srikar Dronamraju wrote:
Here is a summary of the Comments and actions that need to be taken for
the current uprobes patchset. Please let me know if I missed or
misunderstood any of your comments.
1. Uprobes depends on trap signal.
Uprobes
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 form.
Agreed, uprobes is still not upstream ready -- it was an RFC. We are
working through the comments there to
On Mon, Jan 18, 2010 at 02:13:25PM +0200, Pekka Enberg wrote:
Hi Avi,
On Mon, 2010-01-18 at 14:01 +0200, Avi Kivity wrote:
Maybe you place no value on uprobes. But people who debug userspace
likely will see a reason.
On 01/18/2010 02:06 PM, Peter Zijlstra wrote:
I do see value in
On Mon, Jan 18, 2010 at 06:52:32PM +0200, Avi Kivity wrote:
On 01/18/2010 05:43 PM, Ananth N Mavinakayanahalli wrote:
Well, the alternatives are very unappealing. Emulation and single-stepping
are going to be very slow compared to a couple of jumps.
So how big chunks of the address
On Fri, Jan 15, 2010 at 10:03:48AM +0100, Peter Zijlstra wrote:
On Thu, 2010-01-14 at 11:46 -0800, Jim Keniston wrote:
discussed elsewhere.
Thanks for the pointer...
:-)
Peter,
I think Jim was referring to
http://sources.redhat.com/ml/systemtap/2007-q1/msg00571.html
Ananth
On Fri, Jan 15, 2010 at 11:13:32AM +0100, Peter Zijlstra wrote:
On Fri, 2010-01-15 at 15:40 +0530, Ananth N Mavinakayanahalli wrote:
Ideas?
emulate the one instruction?
In kernel? Generically? Don't think its that easy for userspace --
you have the full gamut of instructions to emulate
On Tue, Jan 12, 2010 at 06:36:00AM +0100, Frederic Weisbecker wrote:
On Mon, Jan 11, 2010 at 05:55:53PM +0530, Srikar Dronamraju wrote:
+static const struct utrace_engine_ops uprobe_utrace_ops = {
+ .report_quiesce = uprobe_report_quiesce,
+ .report_signal = uprobe_report_signal,
+
On Mon, Dec 21, 2009 at 07:18:37PM +0530, Ananth N Mavinakayanahalli wrote:
On Fri, Dec 18, 2009 at 02:11:40AM +0100, Oleg Nesterov wrote:
The patch adds the new file, kernel/ptrace-utrace.c, which contains
the new implementation of ptrace over utrace.
This file is not compiled until we
On Fri, Dec 18, 2009 at 02:11:40AM +0100, Oleg Nesterov wrote:
The patch adds the new file, kernel/ptrace-utrace.c, which contains
the new implementation of ptrace over utrace.
This file is not compiled until we have CONFIG_UTRACE option, will be
added by the next utrace core patch.
It's
On Mon, Dec 07, 2009 at 01:43:27PM +0100, Oleg Nesterov wrote:
On 12/06, CAI Qian wrote:
Ananth, could you please confirm once again that step-jump-cont (from
ptrace-tests testsuite) not fail on your machine? If yes, please tell
me the version of glibc/gcc. Is PTRACE_GETREGS defined on your
On Mon, Dec 07, 2009 at 07:05:40PM +0100, Oleg Nesterov wrote:
On 12/07, Oleg Nesterov wrote:
On 12/07, Jan Kratochvil wrote:
On Mon, 07 Dec 2009 15:24:51 +0100, Oleg Nesterov wrote:
But. raise_sigusr2 is not equal to the actual address of
raise_sigusr2(),
this value points
Oleg,
I am confused as to why we need two atomics count and live in signal_struct.
report_death() uses -live as the group_dead indicator, while there are
places (like the scheduler) which uses -count as the nr_threads
indicator.
I tried git blame to see if it remembers why, but the addition
On Fri, Nov 27, 2009 at 04:15:21PM +0100, Oleg Nesterov wrote:
On 11/27, Ananth N Mavinakayanahalli wrote:
I am confused as to why we need two atomics count and live in signal_struct.
report_death() uses -live as the group_dead indicator,
report_death? Perhaps you meant do_exit
On Fri, Nov 27, 2009 at 06:46:27PM +0100, Veaceslav Falico wrote:
On Thu, Nov 26, 2009 at 11:37:03PM +0100, Oleg Nesterov wrote:
Could you look at this
ptrace-copy_process-should-disable-stepping.patch
http://marc.info/?l=linux-mm-commitsm=125789789322573
patch? It is not clear
On Thu, Nov 26, 2009 at 03:50:51PM +0100, Oleg Nesterov wrote:
I changed the subject. This bug has nothing to do with utrace,
the kernel fails with or without these changes.
On 11/26, Ananth N Mavinakayanahalli wrote:
On Wed, Nov 25, 2009 at 04:40:52PM +0100, Oleg Nesterov wrote:
On 11
On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote:
Hello.
This is the new iteration of Roland's utrace patch, this time
with rewrite-ptrace-via-utrace + cleanups in utrace core.
1-7 are already in -mm tree, I am sending them to simplify the
review.
8-12 don not change the
Hi,
Here is the summary of GDB testsuite runs on a vanilla kernel and one
with ptrace over utrace on a powerpc machine:
Vanilla ptrace:
=== gdb Summary ===
# of expected passes13970
# of unexpected failures52
# of unexpected successes 2
# of expected
On Wed, Nov 25, 2009 at 04:40:52PM +0100, Oleg Nesterov wrote:
On 11/25, Ananth N Mavinakayanahalli wrote:
I ran the ptrace-tests testsuite [1] on powerpc on the vanilla ptrace
and then with ptrace/utrace. The results for ptrace/utrace look better
:-)
Great! thanks a lot Ananth
On Tue, Nov 24, 2009 at 04:26:57PM +0100, Oleg Nesterov wrote:
On 11/24, Ananth N Mavinakayanahalli wrote:
...
step-jump-cont: step-jump-cont.c:140: pokeuser: Assertion `l == 0'
failed.
/bin/sh: line 4: 9070 Aborted ${dir}$tst
FAIL: step-jump-cont
errno 14 (Bad
On Thu, Oct 29, 2009 at 08:41:58PM +0100, Oleg Nesterov wrote:
On 10/27, Roland McGrath wrote:
@@ -495,8 +494,8 @@ static u32 ptrace_report_signal(u32 acti
context-siginfo = NULL;
if (resume != UTRACE_RESUME) {
-
On Wed, Oct 28, 2009 at 06:55:32PM -0700, Roland McGrath wrote:
Please take a look at the patch below and tell me what you think. This
is the new(ish) utrace-indirect branch (not to be confused with what's
now old/utrace-indirect). I first made it a while ago, but I don't
recall if I ever
Trivial patch - looks like this was opencoded rather than using the helper
Use set_stop_code() wherever possible.
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
---
kernel/ptrace.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: ptrace-13oct/kernel/ptrace.c
Rename ptrace_context() to get_ptrace_context() and use it for better
code readability. (I know it doesn't take a ref or anything; feel free to
ignore)
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
---
kernel/ptrace.c | 40 +---
1 file changed
On Sat, Sep 05, 2009 at 06:01:58PM +0300, Ali Polatel wrote:
Hey everyone,
I've been writing a ptrace based sandboxing tool, called sydbox¹, and I
want to explain about some of my bad experiences with ptrace and whether
utrace will fix these deficiencies.
First of all ptrace() makes it
On Fri, Sep 04, 2009 at 02:55:29AM -0700, Roland McGrath wrote:
Simple answer. Because I do not know how to implement this. At least now.
I tried to think of this more, but I don't see how to make the first steps.
(Yes, to be honest, this looks like unnecessary complication to me, I have
Oleg,
From conversations between you and Roland, it looks like you're
reworking quite a bit of the ptrace/utrace code. Wondering if you are
hosting your changes in a git tree/branch?
Regards,
Ananth
This series is an RFC for utrace-based non-disruptive application core
dumper. Per Roland McGrath, this is possibly one of the common use-cases
for utrace.
This is the first foray of mine into the hairy core dump land.
Admittedly, I may have missed some (not so) subtle issues that need
careful
Create the /proc/pid/gen-core file that is the trigger for non-disruptive
application core dumps. Writing any value other than 1 to this file is
invalid.
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
---
fs/proc/Makefile |1
fs/proc/base.c |3 ++
fs/proc
More than one user has hit the -EEXIST problem when using
utrace_attach_task and UTRACE_ATTACH_EXCLUSIVE without
UTRACE_ATTACH_MATCH_DATA|_OPS. Document that a bit more.
Signed-off-by: Ananth N Mavinakayanahalli ana...@in.ibm.com
---
kernel/utrace.c |4
1 file changed, 4 insertions
On Mon, Mar 23, 2009 at 10:54:09PM -0700, Andrew Morton wrote:
On Tue, 24 Mar 2009 10:59:26 +0530 Ananth N Mavinakayanahalli
ana...@in.ibm.com wrote:
On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
On Sat, 21 Mar 2009 07:51:41 -0400 Frank Ch. Eigler f...@redhat.com
On Sat, Mar 21, 2009 at 05:04:22AM -0700, Andrew Morton wrote:
On Sat, 21 Mar 2009 07:51:41 -0400 Frank Ch. Eigler f...@redhat.com wrote:
On Sat, Mar 21, 2009 at 04:19:54AM -0700, Andrew Morton wrote:
I have strong memories of being traumatised by reading the uprobes code.
That was a long
Roland,
With the current utrace/master tree, I am seeing that utrace_attach_task()
never returns when invoked from the clone callback. The same module
works fine with prior utrace (rcu as well as with my embed version).
The testcase is simple:
a. attach an engine to attachstop-mt (from the gdb
On Fri, Mar 06, 2009 at 12:52:34PM -0800, Roland McGrath wrote:
With the current utrace/master tree, I am seeing that utrace_attach_task()
never returns when invoked from the clone callback. The same module
works fine with prior utrace (rcu as well as with my embed version).
I changed the
On Fri, Mar 06, 2009 at 12:52:34PM -0800, Roland McGrath wrote:
With the current utrace/master tree, I am seeing that utrace_attach_task()
never returns when invoked from the clone callback. The same module
works fine with prior utrace (rcu as well as with my embed version).
I changed the
On Wed, Jan 21, 2009 at 11:58:25AM +0530, Ananth N Mavinakayanahalli wrote:
On Mon, Jan 19, 2009 at 03:20:31PM -0800, Roland McGrath wrote:
Thanks for working on this, Ananth. (Btw, it's embed.)
I think it would be less disruptive (and materially no different)
to leave utrace_flags
Roland,
What are your thoughts of getting utrace git tree into linux-next?
That way, utrace will have more extensive visibility and testing.
Ananth
From: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
utrace_stop() seems to get the spin_unlock sequence inverted in one of the
unlikely branches. Fix it.
Signed-off-by: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
---
kernel/utrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
Roland,
Occasionally, I see:
attached to 1717 = 0xde089000
utrace_control: -EINPROGRESS
pid 1717 reports quiesced to 0xde089000
BUG: sleeping function called from invalid context at kernel/sched.c:5428
in_atomic():0, irqs_disabled():1
no locks held by uttest/1717.
irq event stamp: 1396
hardirqs
On Wed, Aug 20, 2008 at 11:48:00AM -0700, Roland McGrath wrote:
Thanks for the report, Ananth.
Ah! The i386 will enter do_notify_resume() with interrupts disabled.
Other machines don't do this (x86-64 and powerpc64, anyway). It is often
harmless, because if TIF_SIGPENDING is set, we'll
On Tue, Aug 05, 2008 at 07:20:42PM -0700, Roland McGrath wrote:
Yes!
[...]
What is the use case for a utrace client to do a utrace_engine_get/put()?
Wouldn't it be more robust if utrace implicitly handles refcounts as
you've detailed below?
If the only operations that affect this count
On Thu, Jul 31, 2008 at 03:38:02PM -0700, Roland McGrath wrote:
...
I think this can be a good model to use for non-perturbing quiesce for
cases as breakpoint insertion and removal or any applicaton text
modification, where one needs to ensure no thread is executing in the
vicinity of
On Wed, Jul 30, 2008 at 04:19:44PM -0500, David Smith wrote:
...
@@ -197,14 +224,33 @@ static void __exit exit_crash_suspend(vo
error, t-pid);
}
else {
- int ret = utrace_control(t, engine, UTRACE_DETACH);
Roland,
Here is a minor fix for powerpc syscalls.h.
---
From: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
Remove return 0 from static inline void syscall_set_arguments()
in powerpc/syscalls.h
---
include/asm-powerpc/syscall.h |1 -
1 file changed, 1 deletion(-)
Index: kernel-utrace-8jul
to ensure ptrace-utrace co-operation patch builds on
powerpc to aid in testing/debug. Srini's task_pt_regs() patch is also
required for the build to be successful.
Signed-off-by: Ananth N Mavinakayanahalli [EMAIL PROTECTED]
---
kernel/ptrace.c | 25 +
1 file changed, 25
On Wed, Jan 30, 2008 at 12:22:58PM -0800, Roland McGrath wrote:
The generic and x86 code for user_regset went into Linus's kernel tree today,
destined for the 2.6.25 release. I'm very grateful to Ingo Molnar, who helped
this happen via the x86.git tree. I've also had some positive feedback
On Tue, Nov 20, 2007 at 08:29:19PM -0800, Roland McGrath wrote:
Here are the steps I have in mind. I think this work should be pretty well
clear to merge upstream without much controversy. Basically, this is the
arch parts now done in the tracehook and regset patches, with a little
sugar.
54 matches
Mail list logo
