On Thu, Aug 02, 2007 at 04:31:12PM +0400, Alexey Dobriyan wrote:
> On Wed, Aug 01, 2007 at 10:55:39PM -0700, Roland McGrath wrote:
> > Here are outstanding problems (aside from TODO items) I know of off hand.
> > These range from bug reports I haven't looked into, to subtle old XXX
> > comments for
On Wed, Sep 12, 2007 at 06:28:06PM -0700, Roland McGrath wrote:
> Hi. Can you help me understand why arch/powerpc/kernel/traps.c's
> single_step_exception and emulate_single_step functions clear the trace
> flags (MSR_SE et al) on every trace trap?
>
> The users of this bit that I know in any det
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.
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.
On Tue, Jan 22, 2008 at 06:30:41PM -0800, Roland McGrath wrote:
> The only things akin to specific plans I have in mind are those I've
> discussed before and that are already on the TODO list. In particular,
> the "engine interaction issues" area comes to mind. (See
> https://www.redhat.com/arch
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, May 13, 2008 at 09:29:04PM -0700, Roland McGrath wrote:
>
> What I have right now is a version where utrace is enabled alongside
> the old ptrace implementation. The hooks into core code are cleaned
> up via tracehook.h, but ptrace still works the same old way. With
> this, they both wor
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-
On Tue, Jul 08, 2008 at 04:37:55PM +0530, Ananth N Mavinakayanahalli wrote:
> Roland,
>
> Here is a minor fix for powerpc syscalls.h.
A similar change is required for sparc64 too...
---
From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
Remove return 0 from sta
ike gdb.
A simple update 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 +
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_DETA
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
> > vicini
On Mon, Aug 04, 2008 at 04:49:21PM -0500, David Smith wrote:
> Roland McGrath wrote:
...
Roland, David,
> > 4. So, what's the plan?
> >
> > I need folks who might use global tracing to answer these questions:
> >
> >a. Do we want it?
>
> Yes. Systemtap currently does "global" tracing no
On Mon, Aug 04, 2008 at 12:20:56PM -0700, Roland McGrath wrote:
...
> The callback synchronization thing is simpler when we have an engine
> pointer that can be relied on, even when you block. I'm guessing
> everyone will be happy to see reference counts replace RCU in the
> interface for deali
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
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
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(+)
From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
In utrace_set_events, setting target->utrace_flags is superfluous in the
DEATH_EVENTS check conditional since it's anyway done unconditionally
later, unless I am missing a possible race for which this was introduced
in the first
On Fri, Sep 12, 2008 at 05:44:59PM -0700, Roland McGrath wrote:
> See the comment above that block, about holding tasklist_lock while setting.
Oops! I missed the exit_notify() part. Thanks for pointing it out.
Ananth
Roland,
What are your thoughts of getting utrace git tree into linux-next?
That way, utrace will have more extensive visibility and testing.
Ananth
for unfinished jobs
---
Fix kernel build when CONFIG_UTRACE_PTRACE=n.
Signed-off-by: Ananth N Mavinakayanahalli
Index: utrace-15jan/kernel/ptrace.c
===
--- utrace-15jan.orig/kernel/ptrace.c 2009-01-12 07:40:20.0 +0530
ed.
/bin/sh: line 4: 32479 Aborted ${dir}$tst
FAIL: step-jump-cont
errno 14 (Bad address)
syscall-reset: syscall-reset.c:95: main: Assertion `(*__errno_location ()) ==
38' failed.
unexpected child status 67f
FAIL: syscall-reset
Signed-off-by: Ananth N Mavinakayanahalli
On Mon, Jan 19, 2009 at 03:20:31PM -0800, Roland McGrath wrote:
> (Btw, it's "embed.")
Indeed :-)
> I think it would be less disruptive (and materially no different)
> to leave utrace_flags as it is. That field is the one (and only)
> that is used in hot paths (or used anywhere outside utrace.c
the comments appropriately. Please feel free to
modify them as you consider fit.
Signed-off-by: Ananth N Mavinakayanahalli
---
include/linux/sched.h |3
include/linux/tracehook.h | 16 --
include/linux/utrace.h| 48 --
kernel/ptrace.c | 11 +
kernel/utrace.c
).
Applies atop the rcu removal patch sent last week:
https://www.redhat.com/archives/utrace-devel/2009-January/msg00075.html
Signed-off-by: Ananth N Mavinakayanahalli
---
include/linux/utrace.h |1
kernel/utrace.c| 99 -
2 files
On Mon, Feb 09, 2009 at 06:05:56PM -0500, Masami Hiramatsu wrote:
> Jim Keniston wrote:
> > On Fri, 2009-02-06 at 15:49 -0500, Masami Hiramatsu wrote:
> >> Hi Jim,
> >>
> >> I'm also interested in the instruction decoder.
> >> If you don't mind, could we share the API specification?
> >> I'd like t
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 m
On Mon, Mar 02, 2009 at 04:07:54AM -0800, Roland McGrath wrote:
> Hi, Ananth. Sorry everything has slid so long (again).
> (I have far too many hats and the past month not so many brains!)
I understand. Thanks for the work, Roland.
> Here is my immediate agenda for utrace hacking:
>
> * I have
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 te
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 chan
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 chan
On a CLONE_THREAD, target->real_parent == current->real_parent and not
current. New threads would loop forever here.
Fix utrace_attach_delay() to work correctly with new threads.
Signed-off-by: Ananth N Mavinakayanahalli
---
kernel/utrace.c |4 +++-
1 file changed, 3 insertions
On Sun, Mar 08, 2009 at 12:03:30AM +0100, Oleg Nesterov wrote:
> Ananth N Mavinakayanahalli wrote:
...
> We can also add "struct task_struct *creator" to "struct utrace". It is
> be set by tracehook_finish_clone/utrace_init_task, and it is cleared by
> traceh
On Mon, Mar 09, 2009 at 11:23:51AM -0700, Roland McGrath wrote:
> > The issue is that target->real_parent == current->real_parent and not
> > current on a CLONE_THREAD|CLONE_PARENT. So we keep looping in the
> > do-while.
>
> Oops! I knew it felt too easy to remove the utrace->cloning field. If
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" 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 time ago
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
> 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&q
On Tue, Mar 24, 2009 at 11:48:49AM +0100, Ingo Molnar wrote:
>
> * Roland McGrath 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
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
---
kernel/utrace.c |4
1 file changed, 4 insertions(+)
Index: utrace
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 con
Create the /proc//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
---
fs/proc/Makefile |1
fs/proc/base.c |3 ++
fs/proc/internal.h |3
utrace layer.
- Do we need the exec callback? Is it implemented correctly here?
- There possibly are more gotchas that am currently unaware of.
Signed-off-by: Ananth N Mavinakayanahalli
---
fs/proc/proc_gencore.c | 354 -
1 file changed, 353 insertio
am yet to determine, causes a failure. As with fatal dumps, gdb is
able to decode the core.
Signed-off-by: Ananth N Mavinakayanahalli
---
fs/proc/proc_gencore.c | 144 +
1 file changed, 144 insertions(+)
Index: utrace-13jul/fs/proc/proc
On Fri, Jul 31, 2009 at 09:59:11AM -0700, Jim Keniston wrote:
>
> On Thu, 2009-07-30 at 15:26 +0530, Ananth N Mavinakayanahalli wrote:
>
> > +static u32 core_clone(enum utrace_resume_action action,
> ...
> > + /*
> > +* -EINPROGRESS =
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
On Tue, Aug 25, 2009 at 06:52:44PM +0200, Oleg Nesterov wrote:
...
> void exit_ptrace(struct task_struct *tracer)
> {
> - struct task_struct *p, *n;
> - LIST_HEAD(ptrace_dead);
> -
> - write_lock_irq(&tasklist_lock);
> - list_for_each_entry_safe(p, n, &tracer->ptraced, ptrace_en
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
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 Mon, Sep 07, 2009 at 04:24:08PM +0300, Ali Polatel wrote:
> Ananth N Mavinakayanahalli yazmış:
> > On Sat, Sep 05, 2009 at 06:01:58PM +0300, Ali Polatel wrote:
>
> I've just checked it out and the interface looks a lot cleaner.
> I'm really impressed, thanks for th
Trivial patch - looks like this was opencoded rather than using the helper
Use set_stop_code() wherever possible.
Signed-off-by: Ananth N Mavinakayanahalli
---
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
---
kernel/ptrace.c | 40 +---
1 file changed, 21 inser
On Mon, Oct 26, 2009 at 04:28:52AM +0100, Oleg Nesterov wrote:
> No functional changes, preparation for utrace-ptrace.
>
> Introduce kernel/ptrace.h and move the code which can be shared
> with the new implementation into this new header.
Did you want this to be a .h? Couldn't this just be a ptra
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
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) {
> - set_stop_code(c
Oleg, Roland,
Here is the ptrace-tests results of a run of this patchset applied on
2.6.32-rc5 (rc8 barfs on boot, unrelated to utrace) on a POWER5 lpar:
make check-TESTS
make[3]: Entering directory `/home/ananth/utrace/ptrace-tests/tests'
PASS: ptrace-on-job-control-stopped
PASS: attach-wait-on
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
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 ch
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 fai
On Wed, Nov 25, 2009 at 10:02:22AM +0100, Jan Kratochvil wrote:
> On Wed, 25 Nov 2009 09:59:11 +0100, Ananth N Mavinakayanahalli wrote:
> > Essentially, there is *no* change in any of the numbers with and without
> > ptrace over utrace.
>
> While it is probable so please rat
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
> > :
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 +0
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 pr
On Fri, Nov 27, 2009 at 04:05:31PM +0100, Oleg Nesterov wrote:
> On 11/27, Ananth N Mavinakayanahalli wrote:
> >
> > On Thu, Nov 26, 2009 at 03:50:51PM +0100, Oleg Nesterov wrote:
> >
> > > Ananth, could you please run the test-case from the changelog
> > >
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,
>
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-commits&m=125789789322573
> >
> > patch? I
On Fri, Nov 27, 2009 at 03:43:56PM +0100, Jan Kratochvil wrote:
> On Fri, 27 Nov 2009 15:34:05 +0100, Oleg Nesterov wrote:
> > Jan, if you see something particular which needs more attention or should
> > be fixed, please let me know. I'll try to investigate then.
>
> I am still not finished with
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 y
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(),
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.
> >
> >
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.
>
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 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 10:50:14AM +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 15:08 +0530, Ananth N Mavinakayanahalli wrote:
> > 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:
> >
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 g
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 s
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 o
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 Wed, Jan 20, 2010 at 07:28:34AM +0100, Ingo Molnar wrote:
>
> * Ananth N Mavinakayanahalli wrote:
>
> > On Wed, Jan 20, 2010 at 06:49:50AM +0100, Ingo Molnar wrote:
...
> > On the other hand, having ptrace/utrace in the -next tree will give it a
> > lot more tes
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 import
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.
> Upro
On Sat, Jan 23, 2010 at 12:23:33PM +0100, Ingo Molnar wrote:
>
> * Kyle Moffett wrote:
>
> > On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
> > wrote:
...
> In that sense it might be better to fix/enhance ptrace, if there's interest.
> I've written a handful of ptrace extensions in the past
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 do
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
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
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 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 kprobes hackers vanished the day the original kprobes code went u
On Fri, Jan 29, 2010 at 01:22:40PM +0530, Ananth N Mavinakayanahalli 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 leavi
On Fri, Jan 29, 2010 at 10:11:16AM +0100, Ingo Molnar wrote:
>
> * Ananth N Mavinakayanahalli 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 ba
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
> (
89 matches
Mail list logo
