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 d
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 comm
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 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 pa
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_ATOM
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
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 we
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
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 functio
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. R
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 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 use
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 w
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 kretp
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 task
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:
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 en
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 re
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 linux-k
21 matches
Mail list logo
