On 2/5/08, Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:
> + * Build and insert the kernel module as done in the kprobe example.
> + * You will see the trace data in /var/log/messages and on the console
> + * whenever sys_open() returns a negative value.
A passing observation"sys_open
Add a timespec style comparison function. Allows two ktime types to be compared
without having to convert to timespec/timeval. Useful for modules doing ktime
based math, especially the ones using ktime_get heavily.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff --git a/include
On 1/29/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
> In that case, why don't you just reduce the priority of kprobe_exceptions_nb?
> Then, the execution path becomes very simple.
Ananth mentioned that the kprobe notifier has to be the first to run.
It still wouldnt allow us to notice breakpoi
On 1/29/08, Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:
> > May be I'm completely off the mark here, but shouldn't a small subset
> > of this section simply be 'breakpoint-free' rather than 'kprobe-free'?
> > Placing a breakpoint on kprobe_handler (say) can loop into a recursive
> > trap
On 1/29/08, Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:
> > Non kprobe breakpoints in the kernel might lie inside the .kprobes.text
> > section. Such breakpoints can easily be identified by in_kprobes_functions
> > and can be caught early. These are problematic and a warning should be
iew it
shouldn't matter. In any case, nothing can be done if the kprobe
exception notifier is circumvented.
> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Products (America) Inc.
> Software Solutions Division
>
> e-mail: [EMAIL PROTECTED]
--
Thanks,
Abhish
On 1/28/08, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Neither the changelog nor the newly-added documentation explain why Linux
> needs this feature. What will it be used for??
There's a detailed discussion along with an example on this thread:
http://lkml.org/lkml/2007/11/13/58
and a bit on:
h
re Solutions Division
>
> e-mail: [EMAIL PROTECTED]
Thanks,
Abhishek Sagar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sam Ravnborg wrote:
> Small static functions are preferred over macros.
> Any particular reason to use a macro here?
>
> Sam
These macros have very limited(two) instantiations. But here's an alternative
patch inlined.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED
Identify breakpoints in .kprobes.text section. These certainly aren't kprobe
traps. However, we make an exception for the breakpoint hardcoded into
jprobe_return.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kpro
Encapsulate reusable code .
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index a99e764..45f2949 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/kernel/kprobes.c
@@ -74,6 +74,13 @@ DEFINE_PER_CPU(
occur).
For this, a check can route the trap handling of such breakpoints away from
kprobe_handler (which ends up calling even more functions marked as __kprobes)
from inside kprobe_exceptions_notify.
All comments/suggestions are welcome.
--
Thanks & Regards,
Abhishek Sagar
--
To unsubscribe
Moving in_kprobes_functions to linux/kprobes.h to share it with
arch/x86/kerne/kprobes.c.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 6168c0a..2762145 100644
--- a/include/linux/kprobes.h
+++ b/include
ifies the kprobe smoke tests to include an entry-handler during the
kretprobe sanity test.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff -upNr -X /home/guest/patches/dontdiff.txt
linux-2.6.24-rc8-mm1/Documentation/kprobes.txt
linux-2.6.24-rc8-mm1_kp/Documentation/kprobes.tx
cases leading up to KPROBE_HIT_SS are possible bugs. Identify and WARN_ON such
cases.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 93aff49..afb5c96 100644
--- a/arch/x86/kernel/kprobes.c
+++ b/arch/x86/
a probe. So
instead of singlestepping we'll let the kernel handle it. If it cant,
it'll panic/die() for us. I'll try to cleanup this case and
incorporate these suggestions in a separate patch, as u suggested.
> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Pr
Now I think your original suggestion is correct.
> Please fix it in another patch.
Ok.
> --
> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Products (America) Inc.
> Software Solutions Division
>
> e-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]
Thanks,
Abhishek Sa
t; Why would you avoid using mutiple "return"s in this function?
>>> I think you can remove "ret" from this function.
>> Hmm...there the are no deeply nested if-elses nor overlapping paths
>> which need to be avoided. All the nested checks unroll cleanly too.
>
On 1/2/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
> I think setup_singlestep() in your first patch is better, because it avoided
> code duplication(*).
Will retain it then.
> > static int __kprobes reenter_kprobe(struct kprobe *p, struct pt_regs *regs,
> >
On 1/2/08, Harvey Harrison <[EMAIL PROTECTED]> wrote:
> > +#if !defined(CONFIG_PREEMPT) || defined(CONFIG_PM)
> > +static __always_inline int setup_boost(struct kprobe *p, struct pt_regs
> > *regs)
> > +{
> > + if (p->ainsn.boostable == 1 && !p->post_handler) {
> > + /* Boost up --
sn == BREAKPOINT_INSTRUCTION)
> > {
> > + regs->eflags &= ~TF_MASK;
> > + regs->eflags |=
> > + kcb->kprobe_saved_eflags;
> > +
it
> mm
>
> (do subsequent pulls via "git-pull --force", as we frequently rebase the
> git tree. NOTE: this might override your own local changes, so do this
> only if you dont mind about losing thse changes in that tree.)
>
Thanks for pointing me to the right tree. I have
dler of the ARM kprobes port. This
further simplifies the current x86 kprobe_handler. The resulting definition is
smaller, more readable, has no goto's and contains only a single call to
get_kprobe.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
Signed-off-by: Quentin Barnes <[EMAI
andler_kretpro
> >struct kretprobe_instance, uflist);
> > ri->rp = rp;
> > ri->task = current;
> > +
> > + if (rp->entry_handler) {
> > + if (rp->entry_handler(ri, regs)) {
>
> C
n instance based on Kevin Stafford's "data pouch" approach.
Kretprobe usage example in Documentation/kprobes.txt has also been
updated to demonstrate the usage of entry-handlers.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff -upNr linux-2.6.24-rc2/Documentation/
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
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) be
> > function entry */
> > > > }
> > > >
> > > > /* will only be called iff flag == 1 */
> > > > int my_return_handler(struct kretprobe_instance *ri, struct pt_regs
> > > > *regs)
> > > > {
> > > > BUG_ON(!flag
n time, this would let user handlers do
the allocation and allow them to use different kinds of data
structures per-instance.
- Abhishek Sagar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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 cal
retprobe_instance *ri, struct pt_regs *regs)
{
BUG_ON(!flag);
exit = sched_clock();
set_bit(0, &flag);
}
I think something like this should do the trick for you.
> Thanks
> Srinivasa DS
--
Thanks & Regards
Abhishek Sagar
-
To unsubscribe from this list: send the line
ogether. So
if the entry-handler fails, no return handler gets called.
Does this address your concerns?
--
Regards
Abhishek Sagar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.o
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 compl
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 "
Perhaps it is even
possible to do this in the kernel currently somehow...?
--
Abhishek Sagar
-
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 9/26/07, Ananth N Mavinakayanahalli <[EMAIL PROTECTED]> wrote:
> PS: There was a thought of providing a facility to run a handler at
> function entry even when just a kretprobe is used. Maybe we need to
> relook at that; it'd have been useful in this case.
That would be really useful. I was wr
(not subscribed to LKML).
>
> Thanks,
> Avishay
>
--
Regards
Abhishek Sagar
-
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
ones I chose to
bring them under the purview of --ffunction-sections. My observation
remains that if a fine-grained function/data/exported-symbol level
garbage collection can be incorporated into the build environment,
then it'll be something really useful.
--
Abhishek Sagar
---
diff -upNr li
on quite an older 2.6 kernel for a while now. I
derived that port from:
http://lkml.org/lkml/2006/6/4/169
With some tweaks it worked for me. Could you also have a look at the
mentioned link and see if that's a superset of what you're trying to
achieve?
--
Abhishek Sagar
-
To unsubscrib
ds to an empty menu for any kernel
configuration. I suspect that this is why the EXPERIMENTAL check is on
the instrumentation menu in the first place.
my original point was simply that, based on its acceptance, it would
seem kprobes has progressed beyond the EXPERIMENTAL phase, that's al
On 7/2/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
On Mon, 2 Jul 2007, Abhishek Sagar wrote:
> On 7/1/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > isn't kprobes mature enough to not be considered experimental anymore?
>
> That would vary from arch to
kprobes across different
archs. It can be cleaned up I suppose.
--
Abhishek Sagar
P.S: Adding systemtap in CC.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/maj
? Core kernel functions would not be
> ending with a 'jprobe_return()' anyway.
There's jprobe code in net/ipv4/tcp_probe.c and net/dccp/probe.c that
can be builtin or modular, so I think kernel_text_address() is right.
Ok..thanks for that clarification.
--
Abhishek Sagar
-
To u
probe handler to be within
kernel/module range. Why not narrow this down to just module range
(!module_text_address(addr), say)? Core kernel functions would not be
ending with a 'jprobe_return()' anyway.
--
Abhishek Sagar
-
To unsubscribe from this list: send the line "unsubscribe linu
45 matches
Mail list logo
