On Wed, 2007-11-21 at 15:50 +0530, Abhishek Sagar wrote:
> On 11/21/07, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > I have one minor suggestion on the code -- see below -- but I'm willing
> > to ack that with or without the suggested change. Please also see
> > suggestions on kprobes.txt and the
On Wed, 2007-11-21 at 15:50 +0530, Abhishek Sagar wrote:
On 11/21/07, Jim Keniston [EMAIL PROTECTED] wrote:
I have one minor suggestion on the code -- see below -- but I'm willing
to ack that with or without the suggested change. Please also see
suggestions on kprobes.txt and the demo
On 11/21/07, Jim Keniston <[EMAIL PROTECTED]> wrote:
> I have one minor suggestion on the code -- see below -- but I'm willing
> to ack that with or without the suggested change. Please also see
> suggestions on kprobes.txt and the demo program.
Thanks...I've made the necessary changes. More
On 11/21/07, Jim Keniston [EMAIL PROTECTED] wrote:
I have one minor suggestion on the code -- see below -- but I'm willing
to ack that with or without the suggested change. Please also see
suggestions on kprobes.txt and the demo program.
Thanks...I've made the necessary changes. More comments
On Mon, 2007-11-19 at 17:56 +0530, Abhishek Sagar wrote:
> On Nov 17, 2007 6:24 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > > True, some kind of data pointer/pouch is essential.
> >
> > Yes. If the pouch idea is too weird, then the data pointer is a good
> > compromise.
> >
> > With the above
On Mon, 2007-11-19 at 17:56 +0530, Abhishek Sagar wrote:
On Nov 17, 2007 6:24 AM, Jim Keniston [EMAIL PROTECTED] wrote:
True, some kind of data pointer/pouch is essential.
Yes. If the pouch idea is too weird, then the data pointer is a good
compromise.
With the above reservations,
On Nov 17, 2007 6:24 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > True, some kind of data pointer/pouch is essential.
>
> Yes. If the pouch idea is too weird, then the data pointer is a good
> compromise.
>
> With the above reservations, your enclosed patch looks OK.
>
> You should provide a
On Nov 17, 2007 6:24 AM, Jim Keniston [EMAIL PROTECTED] wrote:
True, some kind of data pointer/pouch is essential.
Yes. If the pouch idea is too weird, then the data pointer is a good
compromise.
With the above reservations, your enclosed patch looks OK.
You should provide a patch #2
On Nov 17, 2007 6:24 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> It'd be helpful to see others (especially kprobes maintainers) chime in
> on this. In particular, if doing kmalloc/kfree of GFP_ATOMIC data at
> kretprobe-hit time is OK, as in Abhishek's approach, then we could also
> use
On Nov 17, 2007 4:39 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> First of all, as promised, here's what would be different if it were
> implemented using the data-pouch approach:
>
> --- abhishek1.c 2007-11-16 13:57:13.0 -0800
> +++ jim1.c 2007-11-16 14:20:39.0 -0800
> @@
On Nov 17, 2007 4:39 AM, Jim Keniston [EMAIL PROTECTED] wrote:
First of all, as promised, here's what would be different if it were
implemented using the data-pouch approach:
--- abhishek1.c 2007-11-16 13:57:13.0 -0800
+++ jim1.c 2007-11-16 14:20:39.0 -0800
@@ -50,15
On Nov 17, 2007 6:24 AM, Jim Keniston [EMAIL PROTECTED] wrote:
It'd be helpful to see others (especially kprobes maintainers) chime in
on this. In particular, if doing kmalloc/kfree of GFP_ATOMIC data at
kretprobe-hit time is OK, as in Abhishek's approach, then we could also
use GFP_ATOMIC
It'd be helpful to see others (especially kprobes maintainers) chime in
on this. In particular, if doing kmalloc/kfree of GFP_ATOMIC data at
kretprobe-hit time is OK, as in Abhishek's approach, then we could also
use GFP_ATOMIC (or at least GFP_NOWAIT) allocations to make up the
difference when
On Sat, 2007-11-17 at 00:23 +0530, Abhishek Sagar wrote:
> On Nov 16, 2007 5:37 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-11-15 at 20:30 +0530, Abhishek Sagar wrote:
> > > On Nov 15, 2007 4:21 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > > > 2. Simplify the task of
On Nov 16, 2007 5:37 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-11-15 at 20:30 +0530, Abhishek Sagar wrote:
> > On Nov 15, 2007 4:21 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > > 2. Simplify the task of correlating data (e.g., timestamps) between
> > > function entry and
On Nov 16, 2007 2:46 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > > Lacking a solution to #1a, I think Abhishek's approach provides a
> > > reasonable solution to problem #1.
> >
> > If you're not convinced that problem #1 isn't appropriately handled,
>
> I don't know where you got that idea.
On Nov 16, 2007 2:46 AM, Jim Keniston [EMAIL PROTECTED] wrote:
Lacking a solution to #1a, I think Abhishek's approach provides a
reasonable solution to problem #1.
If you're not convinced that problem #1 isn't appropriately handled,
I don't know where you got that idea. Reread my last
On Nov 16, 2007 5:37 AM, Jim Keniston [EMAIL PROTECTED] wrote:
On Thu, 2007-11-15 at 20:30 +0530, Abhishek Sagar wrote:
On Nov 15, 2007 4:21 AM, Jim Keniston [EMAIL PROTECTED] wrote:
2. Simplify the task of correlating data (e.g., timestamps) between
function entry and function return.
On Sat, 2007-11-17 at 00:23 +0530, Abhishek Sagar wrote:
On Nov 16, 2007 5:37 AM, Jim Keniston [EMAIL PROTECTED] wrote:
On Thu, 2007-11-15 at 20:30 +0530, Abhishek Sagar wrote:
On Nov 15, 2007 4:21 AM, Jim Keniston [EMAIL PROTECTED] wrote:
2. Simplify the task of correlating data (e.g.,
It'd be helpful to see others (especially kprobes maintainers) chime in
on this. In particular, if doing kmalloc/kfree of GFP_ATOMIC data at
kretprobe-hit time is OK, as in Abhishek's approach, then we could also
use GFP_ATOMIC (or at least GFP_NOWAIT) allocations to make up the
difference when
On Thu, 2007-11-15 at 20:30 +0530, Abhishek Sagar wrote:
> On Nov 15, 2007 4:21 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> > 2. Simplify the task of correlating data (e.g., timestamps) between
> > function entry and function return.
>
> Would adding of data and len fields in ri help? Instead
On Thu, 2007-11-15 at 18:46 +0530, Abhishek Sagar wrote:
> On Nov 15, 2007 4:21 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
...
> > First of all, some general comments. We seem to be trying to solve two
> > problems here:
> > 1. Prevent the asymmetry in entry- vs. return-handler calls that can
>
On Nov 15, 2007 4:21 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> 2. Simplify the task of correlating data (e.g., timestamps) between
> function entry and function return.
Would adding of data and len fields in ri help? Instead of "pouching"
data in one go at registration time, this would let
On Nov 15, 2007 4:21 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-14 at 19:00 +0530, Abhishek Sagar wrote:
>
> First of all, some general comments. We seem to be trying to solve two
> problems here:
> 1. Prevent the asymmetry in entry- vs. return-handler calls that can
> develop
On Nov 15, 2007 4:21 AM, Jim Keniston [EMAIL PROTECTED] wrote:
On Wed, 2007-11-14 at 19:00 +0530, Abhishek Sagar wrote:
First of all, some general comments. We seem to be trying to solve two
problems here:
1. Prevent the asymmetry in entry- vs. return-handler calls that can
develop when we
On Nov 15, 2007 4:21 AM, Jim Keniston [EMAIL PROTECTED] wrote:
2. Simplify the task of correlating data (e.g., timestamps) between
function entry and function return.
Would adding of data and len fields in ri help? Instead of pouching
data in one go at registration time, this would let user
On Thu, 2007-11-15 at 18:46 +0530, Abhishek Sagar wrote:
On Nov 15, 2007 4:21 AM, Jim Keniston [EMAIL PROTECTED] wrote:
...
First of all, some general comments. We seem to be trying to solve two
problems here:
1. Prevent the asymmetry in entry- vs. return-handler calls that can
develop
On Thu, 2007-11-15 at 20:30 +0530, Abhishek Sagar wrote:
On Nov 15, 2007 4:21 AM, Jim Keniston [EMAIL PROTECTED] wrote:
2. Simplify the task of correlating data (e.g., timestamps) between
function entry and function return.
Would adding of data and len fields in ri help? Instead of
On Wed, 2007-11-14 at 19:00 +0530, Abhishek Sagar wrote:
First of all, some general comments. We seem to be trying to solve two
problems here:
1. Prevent the asymmetry in entry- vs. return-handler calls that can
develop when we temporarily run out of kretprobe_instances. E.g., if we
have m
On Nov 14, 2007 3:53 PM, Srinivasa Ds <[EMAIL PROTECTED]> wrote:
> No, eventhough return instances are chained in an order, order of execution of
> return handler entirely depends on which process returns first
Right...the LIFO chain analogy holds true for return instances for the
same task only.
Abhishek Sagar wrote:
the entry handler is called with the appropriate return instance. I
haven't put any explicit "match" test here for ri. The reason is that
the correct ri would be passed to both the entry and return handlers
as trampoline_handler() explicitly matches them to the correct
On Nov 14, 2007 1:27 PM, Srinivasa Ds <[EMAIL PROTECTED]> wrote:
> 1) How do you map the entry_handler(which gets executed when a process enters
> the function) with each instance of return probe handler.
> I accept that entry_handler() will execute each time process enters the
> function, but
On Nov 14, 2007 1:27 PM, Srinivasa Ds [EMAIL PROTECTED] wrote:
1) How do you map the entry_handler(which gets executed when a process enters
the function) with each instance of return probe handler.
I accept that entry_handler() will execute each time process enters the
function, but to
Abhishek Sagar wrote:
the entry handler is called with the appropriate return instance. I
haven't put any explicit match test here for ri. The reason is that
the correct ri would be passed to both the entry and return handlers
as trampoline_handler() explicitly matches them to the correct task.
On Nov 14, 2007 3:53 PM, Srinivasa Ds [EMAIL PROTECTED] wrote:
No, eventhough return instances are chained in an order, order of execution of
return handler entirely depends on which process returns first
Right...the LIFO chain analogy holds true for return instances for the
same task only. As
On Wed, 2007-11-14 at 19:00 +0530, Abhishek Sagar wrote:
First of all, some general comments. We seem to be trying to solve two
problems here:
1. Prevent the asymmetry in entry- vs. return-handler calls that can
develop when we temporarily run out of kretprobe_instances. E.g., if we
have m
Abhishek Sagar wrote:
On Nov 13, 2007 12:09 AM, Abhishek Sagar <[EMAIL PROTECTED]> wrote:
Whoops...sry for the repeated email..emailer trouble.
Expecting this one to makes it to the list. Summary again:
This patch introduces a provision to specify a user-defined callback
to run at function
On Nov 13, 2007 12:09 AM, Abhishek Sagar <[EMAIL PROTECTED]> wrote:
> Whoops...sry for the repeated email..emailer trouble.
Expecting this one to makes it to the list. Summary again:
This patch introduces a provision to specify a user-defined callback
to run at function entry to complement the
On Nov 13, 2007 12:09 AM, Abhishek Sagar [EMAIL PROTECTED] wrote:
Whoops...sry for the repeated email..emailer trouble.
Expecting this one to makes it to the list. Summary again:
This patch introduces a provision to specify a user-defined callback
to run at function entry to complement the
Abhishek Sagar wrote:
On Nov 13, 2007 12:09 AM, Abhishek Sagar [EMAIL PROTECTED] wrote:
Whoops...sry for the repeated email..emailer trouble.
Expecting this one to makes it to the list. Summary again:
This patch introduces a provision to specify a user-defined callback
to run at function
On Nov 13, 2007 12:01 AM, Abhishek Sagar <[EMAIL PROTECTED]> wrote:
> Hope these simple changes would suffice; all suggestions/corrections are
> welcome.
Whoops...sry for the repeated email..emailer trouble.
--
Regards,
Abhishek
-
To unsubscribe from this list: send the line "unsubscribe
On Nov 13, 2007 12:01 AM, Abhishek Sagar [EMAIL PROTECTED] wrote:
Hope these simple changes would suffice; all suggestions/corrections are
welcome.
Whoops...sry for the repeated email..emailer trouble.
--
Regards,
Abhishek
-
To unsubscribe from this list: send the line unsubscribe
42 matches
Mail list logo
