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/arch/sh
its gdb breakpoint is hit.
Signed-off-by: Jim Keniston jkeni...@linux.vnet.ibm.com
Signed-off-by: Reza Arbab ar...@linux.vnet.ibm.com
Reported-by: Vijay Kumar vkuma...@lenovo.com
Tested-by: Vijay Kumar vkuma...@lenovo.com
---
arch/sh/include/asm/kprobes.h |2 ++
arch/sh/kernel/kprobes.c
>
> 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/
).
...
Signed-off-by: Dave Hansen dave.han...@linux.intel.com
Acked-by: Jim Keniston jkeni...@us.ibm.com
--
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
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 real r
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 Neste
or explain why those bits are not wrong.
No actual code changes.
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: Jim Keniston jkeni...@us.ibm.com
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Srikar Dronamraju sri...@linux.vnet.ibm.com
CC: Ingo Molnar mi...@kernel.org
CC: Oleg
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 jkeni...@us.ibm.com
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
".
>
> 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 |
in arch_uprobe_analyze_insn().
Suggested-by: Jim Keniston jkeni...@us.ibm.com
Signed-off-by: Oleg Nesterov o...@redhat.com
Looks good. Thanks.
Reviewed-by: Jim Keniston jkeni...@us.ibm.com
---
arch/x86/include/asm/uprobes.h |2 +-
arch/x86/kernel/uprobes.c | 37
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.
Th
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
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_(insn) X86_VEX_V((insn
or explain why those bits are not wrong.
No actual code changes.
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: Jim Keniston jkeni...@us.ibm.com
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Srikar Dronamraju sri...@linux.vnet.ibm.com
CC: Ingo Molnar mi...@kernel.org
CC: Oleg
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
> +
mode in instructions such as ... is mishandled.
...
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: Jim Keniston jkeni...@us.ibm.com
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Srikar Dronamraju sri...@linux.vnet.ibm.com
CC: Ingo Molnar mi...@kernel.org
CC: Oleg Nesterov o
y 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
> ++
> 1 file ch
wed-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_uprobe *a
-by: Jim Keniston jkeni...@us.ibm.com
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_uprobe *auprobe, struct pt_regs
...@redhat.com
CC: Jim Keniston jkeni...@us.ibm.com
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Srikar Dronamraju sri...@linux.vnet.ibm.com
CC: Ingo Molnar mi...@kernel.org
CC: Oleg Nesterov o...@redhat.com
---
arch/x86/kernel/uprobes.c | 154
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: Oleg Nester
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
(), and riprel_post_xol() respectively.
No changes in compiled code.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Reviewed-by: Jim Keniston jkeni...@us.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
if/else branches.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Reviewed-by: Jim Keniston jkeni...@us.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
this argument, change riprel_pre_xol() to use current-utask.
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Reviewed-by: Jim Keniston jkeni...@us.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
latest changes and run-tested.
v3: Removed unnecessary cast.
Improved comments based on Oleg's feedback.
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
CC: Jim Keniston jkeni...@us.ibm.com
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Srikar Dronamraju sri...@linux.vnet.ibm.com
CC
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 dvlas...@redhat.com
CC: Jim Keniston jkeni...@us.ibm.com
CC: Masami Hiramatsu masami.hiramatsu...@hitachi.com
CC: Srikar Dronamraju sri
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
ames 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 |
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 body of a mes
patches are:
Reviewed-by: Jim Keniston jkeni...@us.ibm.com
--
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/
to make this name shorter.
Signed-off-by: Oleg Nesterov o...@redhat.com
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 jkeni...@us.ibm.com
---
arch/x86/include/asm/uprobes.h | 12 ++
arch/x86/kernel
On Thu, 2014-04-24 at 19:33 +0200, Oleg Nesterov wrote:
Thanks!
Masami, Jim, any acks?
Acked-by: Jim Keniston jkeni...@us.ibm.com
On 04/24, Denys Vlasenko wrote:
All branch insns on x86 can be prefixed with the operand-size
override prefix, 0x66. It was only ever useful
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
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.kernel.
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
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 your code is solid, but I think
ttt
prefix.
Will you agree with s/ttt/branch/ ?
Yes.
Do you think the code is fine in v2 ?
Yes, except for certain comments wrt call emulation. See my reply about
patch #4 from a few minutes ago.
Once that's resolved, I consider all your patches so far
Reviewed-by: Jim Keniston jkeni
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?
Oleg, thanks for responding to (if not necessarily agreeing
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
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
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
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 jle...@redhat.com
Signed-off-by:
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 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.
---
Subject:
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-relative
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 for m
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
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!!!"
> > > below.
&g
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!!!
below.
insn-moffset1.value seems to be what you want.
Works! Thanks
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
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 for me. I can't find in your patch sets
where
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
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
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 unmapped
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,
please
97 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 majord...
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
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
, ->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 "unsubscribe linux-kernel" in
the b
() altogether, we could just mangle the
problematic instructions and complicate arch_uprobe_post_xol(), but I do
not think this would 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
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())
+
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;
+
+
(noted
elsewhere) that Oleg inherited, it looks good so far.
Reviewed-by: Jim Keniston jkeni...@us.ibm.com
--
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
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
&
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
callback to be run
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
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 where
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
module, the call to get_kprobe() needs
er, 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?
Jim Keniston
>
-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?
Jim Keniston
From Ananth's patch:
+static noinline u32 kprobe_target(u32 value)
+{
+ /*
+* gcc ignores noinline
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
> >
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 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
> >
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
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 is a
> &
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 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
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 is a
generalized case of Srinivasa's timestamp case
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
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
is 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/
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
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 usefulness is greatly
. 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 usefulness is greatly reduced.
Jim Keniston
IBM LTC
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
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 overview :
I am told that
.
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:33:03.0
-07
.
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:33:03.0
-0700
@@ -220,7 +220,10
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.
&
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.
Please apply.
...
+Here's how
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
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/Documentation
1 - 100 of 104 matches
Mail list logo
