when its gdb breakpoint is hit.
Signed-off-by: Jim Keniston
Signed-off-by: Reza Arbab
Reported-by: Vijay Kumar
Tested-by: Vijay Kumar
---
arch/sh/include/asm/kprobes.h |2 ++
arch/sh/kernel/kprobes.c |5 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/ar
;
> Signed-off-by: Dave Hansen
Acked-by: Jim Keniston
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I've at least verified that all your code changes are consistent with
your comments. Ditto for patch #3.
Patches 1-3:
Reviewed-by: Jim Keniston
On Fri, 2014-07-04 at 15:03 +0200, Denys Vlasenko wrote:
> This change fixes 1-byte opcode tables so that only insns
> for which we have r
will fix wrong bits
> or explain why those bits are not wrong.
>
> No actual code changes.
>
> Signed-off-by: Denys Vlasenko
> CC: Jim Keniston
> CC: Masami Hiramatsu
> CC: Srikar Dronamraju
> CC: Ingo Molnar
> CC: Oleg
>
> 3. Remove the stale part of the comment in arch_uprobe_analyze_insn().
>
> Suggested-by: Jim Keniston
> Signed-off-by: Oleg Nesterov
Looks good. Thanks.
Reviewed-by: Jim Keniston
> ---
> arch/x86/include/asm/uprobes.h |2 +-
> arch/x86/kernel/uprobes.c |
will fix wrong bits
> or explain why those bits are not wrong.
>
> No actual code changes.
>
> Signed-off-by: Denys Vlasenko
> CC: Jim Keniston
> CC: Masami Hiramatsu
> CC: Srikar Dronamraju
> CC: Ingo Molnar
> CC: Oleg Nesterov
All of the following is FYI
On Fri, 2014-05-02 at 17:04 +0200, Denys Vlasenko wrote:
> On 05/02/2014 02:48 AM, Jim Keniston wrote:
> > On Thu, 2014-05-01 at 19:09 +0200, Denys Vlasenko wrote:
> >> +#define VEX2_(insn) X86_VEX_V((insn)->vex_prefix.bytes[1])
> >> +#define VEX3_(i
ip-relative addressing
mode in instructions such as ... is mishandled."
...
>
> Signed-off-by: Denys Vlasenko
> CC: Jim Keniston
> CC: Masami Hiramatsu
> CC: Srikar Dronamraju
> CC: Ingo Molnar
> CC: Oleg Nesterov
> ---
> arch/x86/kernel/uprobes.c | 179
> +
creativity on this.
Jim
>
> Signed-off-by: Denys Vlasenko
> CC: Jim Keniston
> CC: Masami Hiramatsu
> CC: Srikar Dronamraju
> CC: Ingo Molnar
> CC: Oleg Nesterov
> ---
> arch/x86/kernel/uprobes.c | 154
> ++
>
ws:
Reviewed-by: Jim Keniston
> On 05/01, Denys Vlasenko wrote:
> >
> > v4: Changed arch_uprobe_xol_was_trapped() comment to reflect new logic.
>
> Hmm. I guess you meant arch_uprobe_post_xol()... please see below.
>
> > static int default_post_xol_op(struct arch
On Mon, 2014-04-28 at 19:06 +0200, Denys Vlasenko wrote:
> Otherwise, instructions such as cmpxchg and div will be mishandled.
>
> Signed-off-by: Denys Vlasenko
> CC: Jim Keniston
> CC: Masami Hiramatsu
> CC: Srikar Dronamraju
> CC: Ingo Molnar
> CC: Oleg Nesterov
d on top of Oleg's latest changes and run-tested.
> v3: Removed unnecessary cast.
> Improved comments based on Oleg's feedback.
>
> Signed-off-by: Denys Vlasenko
> CC: Jim Keniston
> CC: Masami Hiramatsu
> CC: Srikar Dronamraju
> CC: Ingo Molnar
> CC: O
vaddr.
> >
> > Remove this argument, change riprel_pre_xol() to use current->utask.
> >
> > Signed-off-by: Oleg Nesterov
>
> Acked-by: Srikar Dronamraju
>
Reviewed-by: Jim Keniston
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
t;
> > 3. Change these functions to use the new helper and avoid copy-and-paste
> >under if/else branches.
> >
> > Signed-off-by: Oleg Nesterov
>
> Acked-by: Srikar Dronamraju
>
Reviewed-by: Jim Keniston
--
To unsubscribe from this list: send the l
l(), and riprel_post_xol() respectively.
> >
> > No changes in compiled code.
> >
> > Signed-off-by: Oleg Nesterov
>
> Acked-by: Srikar Dronamraju
>
Reviewed-by: Jim Keniston
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Thu, 2014-04-24 at 19:33 +0200, Oleg Nesterov wrote:
> Thanks!
>
> Masami, Jim, any acks?
Acked-by: Jim Keniston
>
> On 04/24, Denys Vlasenko wrote:
> >
> > All branch insns on x86 can be prefixed with the operand-size
> > override prefix, 0x66. It wa
s rip_rela_target_address to riprel_target just
> to make this name shorter.
>
> Signed-off-by: Oleg Nesterov
I see a couple of nits in this patch (see below), but the others look
good.
Patches 1-5 of this set:
Reviewed-by: Jim Keniston
> ---
> arch/x86/include/asm/uprobes.h |
gt; arch/x86/kernel/uprobes.c| 126
> ++++++----
> 2 files changed, 58 insertions(+), 75 deletions(-)
>
These 5 patches are:
Reviewed-by: Jim Keniston
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Wed, 2014-04-09 at 14:25 -0700, Jim Keniston wrote:
> On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
> > On 04/08, Jim Keniston wrote:
> > >
> > > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > > > 0xe8. Anything else?
>
few minutes ago.
Once that's resolved, I consider all your patches so far
Reviewed-by: Jim Keniston
and
Acked-by: Jim Keniston
>
> Oleg.
...
Jim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
On Wed, 2014-04-09 at 17:43 +0200, Oleg Nesterov wrote:
> On 04/08, Jim Keniston wrote:
> >
> > On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > > 0xe8. Anything else?
Oleg, thanks for responding to (if not necessarily agreeing with) all my
suggestions. I think
On Mon, 2014-04-07 at 16:28 +0200, Oleg Nesterov wrote:
> On 04/06, Oleg Nesterov wrote:
> >
> > But I'll try to cleanup this patch...
>
> See v2 below.
>
> ---
> Subject: [RFC PATCH v2 6/6] uprobes/x86: Emulate rip-relat
On Mon, 2014-04-07 at 16:27 +0200, Oleg Nesterov wrote:
> On 04/06, Oleg Nesterov wrote:
> >
> > Incomplete, lacks "jcxz". Simple to fix. Anything else?
>
> Please see v2 below. Simplify the preprocessor hacks.
>
> ---
>
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 0xe8. Anything else?
No, I think e8 is the only call instruction uprobes will see.
>
The following couple of paragraphs should be included in the code,
perhaps merged with some of the related comments already there. Without
it, the code
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 0xeb and 0xe9. Anything else?
For unconditional rip-relative jumps, yes, I'm pretty sure that's it.
>
> TODO: move ->fixup into the union along with rip_rela_target_address.
>
> Reported-by: Jonathan Lebon
> Signed-off-by: Oleg Nesterov
On Mon, 2014-04-07 at 13:34 -0700, Jim Keniston wrote:
> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> > 1. Add the trivial sizeof_long() helper and change other callers of
> >is_ia32_task() to use it.
> >
> ...
>
> This hunk #3 doesn't apply
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 1. Add the trivial sizeof_long() helper and change other callers of
>is_ia32_task() to use it.
>
...
This hunk #3 doesn't apply for me. I can't find in your patch sets
where you added the lines being replaced (and they weren't there
o
On Sun, 2014-04-06 at 22:15 +0200, Oleg Nesterov wrote:
> On 04/04, Jim Keniston wrote:
> >
> > On Fri, 2014-04-04 at 21:32 +0200, Oleg Nesterov wrote:
> > >
> > > 1. Why insn_get_displacement() doesn't work? See "HELP!!!"
> > > belo
On Fri, 2014-04-04 at 21:32 +0200, Oleg Nesterov wrote:
> On 04/04, Oleg Nesterov wrote:
> >
> > Now let me send the draft RFC patch which fixes the "call" handling...
>
> Damn. apparently I can't understand lib/insn.c...
>
> Please see the draft below. Lets ignore 32bit tasks, lets ignore jmp's,
On Fri, 2014-04-04 at 20:51 +0200, Oleg Nesterov wrote:
> SIGILL after the failed arch_uprobe_post_xol() should only be used as
> a last resort, we should try to restart the probed insn if possible.
>
> Currently only adjust_ret_addr() can fail, and this can only happen if
> another thread unmappe
+), 197 deletions(-)
>
I've reviewed all 7 patches. Aside from a couple of nits (noted
elsewhere) that Oleg inherited, it looks good so far.
Reviewed-by: Jim Keniston
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, 2014-03-31 at 21:44 +0200, Oleg Nesterov wrote:
...
> +static void
> +handle_riprel_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs,
> long *correction)
> +{
> + if (auprobe->fixups & (UPROBE_FIX_RIP_AX | UPROBE_FIX_RIP_CX)) {
> + struct arch_uprobe_task *autask;
On Mon, 2014-03-31 at 21:44 +0200, Oleg Nesterov wrote:
...
> +/*
> + * Adjust the return address pushed by a call insn executed out of line.
> + */
> +static int adjust_ret_addr(unsigned long sp, long correction)
> +{
> + int rasize, ncopied;
> + long ra = 0;
> +
> + if (is_ia32_task()
ould be better. And if nothing else, ->emulate is a) simple
> and b) should likely succeed and make the probing faster.
>
> But perhaps I missed something?
>
> Oleg.
>
Jim Keniston
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsu
On Sat, 2008-01-26 at 23:52 +0530, Abhishek Sagar wrote:
> This is a repost of a patch which was reviewed earlier at:
> http://lkml.org/lkml/2007/11/13/58 (thanks to Jim Keniston and Srinivasa for
> their review comments). This provides support to add an optional user defined
> ca
On Wed, 2008-01-09 at 22:21 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 12:24:00PM -0800, Jim Keniston wrote:
> > On Wed, 2008-01-09 at 00:28 +0100, Andi Kleen wrote:
> > > > I have no problem with that, but if we want to make it buildable as a
> > > > modul
On Wed, 2008-01-09 at 00:28 +0100, Andi Kleen wrote:
> > I have no problem with that, but if we want to make it buildable as a
> > module, the call to get_kprobe() needs to be replaced with some other
> > gcc-inline-defeating mechanism, or we need to export get_probe(). I
>
> It's still unclear w
former, since get_kprobe() is a kprobes-internal
function.
Anybody know an architecture-independent way (other than noinline, which
doesn't always work) of making gcc decide not to inline a function?
E.g., does taking (and using) the function's address do it?
Ji
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
> > su
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
> >
rence when we run low on kretprobe_instances.
More comments below.
On Fri, 2007-11-16 at 23:20 +0530, Abhishek Sagar wrote:
> On Nov 16, 2007 2:46 AM, Jim Keniston <[EMAIL PROTECTED]> wrote:
...
>
> > > There are three problems in the "data pouch" approach, which i
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:
&
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
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. re
= sched_clock();
> set_bit(0, &flag);
> }
>
> I think something like this should do the trick for you.
Since flag is static, it seems to me that if there were instances of the
probed function active concurrently in multiple tasks, only the
first-called instance would be profiled.
>
> > Thanks
> > Srinivasa DS
>
> --
> Thanks & Regards
> Abhishek Sagar
Jim Keniston
-
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/
g and controlling user
threads. This is the foundation for writing tracing engines, which
can be loadable kernel modules."
If we can't use utrace to write ad hoc instrumentation modules (i.e.,
because utrace_attach(), utrace_detach(), etc. are no longer exported),
then utrace's usefuln
On Wed, 2007-04-11 at 15:21 -0400, Mathieu Desnoyers wrote:
> * Andrew Morton ([EMAIL PROTECTED]) wrote:
> > On Wed, 11 Apr 2007 13:51:11 -0400
> > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> >
> > > > What's this marker stuff about?
> > > >
> > >
> > > Hi Russel,
> > >
> > > Here is an over
oint in a tight loop.
Please apply.
Acked-by: Prasanna S Panchamukhi <[EMAIL PROTECTED]>
Signed-off-by: Jim Keniston <[EMAIL PROTECTED]>
--- linux-2.6.13/arch/i386/kernel/kprobes.c 2005-08-30 12:27:35.0
-0700
+++ linux-fixed/arch/i386/kernel/kprobes.c 2005-08-30 15:
On Wed, 2005-08-03 at 03:41, Suparna Bhattacharya wrote:
> On Tue, Aug 02, 2005 at 03:20:06PM -0700, Jim Keniston wrote:
> > The enclosed patch creates Documentation/kprobes.txt, a guide to using
> > the existing Kprobes facility for dynamic kernel instrumentation.
&
The enclosed patch creates Documentation/kprobes.txt, a guide to using
the existing Kprobes facility for dynamic kernel instrumentation.
Please apply.
Jim Keniston
Acked-by: Prasanna S Panchamukhi <[EMAIL PROTECTED]>
Signed-off-by: Jim Keniston <[EMAIL PROTECTED]>
--- linux.old/D
On Tue, 2005-04-05 at 10:19, Jim Keniston wrote:
> On Mon, 2005-04-04 at 01:15, Prasanna S Panchamukhi wrote:
> ...
> > int register_returnprobe(struct rprobe *rp) {
> ...
>
> > independent of kprobe and jprobe.
> ...
> >
> > make unregister
n't need to initialize the (nonexistent) rp
pointer. Probably not a huge deal.)
OR
2. Create the ability to (a) register kprobes, jprobes, and/or retprobes
in a disabled state; and (b) enable a group of probes in an atomic
operation. Then you could register the entry and return probes
in
52 matches
Mail list logo
